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Abstract 


Systems  Architectures  for  Downsizing  continues  INPUT'S  series  of  in- 
depth  reports  on  downsizing.  Its  purpose  is  to  examine  the  various  layers 
of  an  informations  systems  architecture  and  assess  the  risks  associated 
with  downsizing.  Many  vendors  and  executives  seem  to  lack  understand- 
ing or  awareness  of  the  problems  and  complexities  of  data  base  manage- 
ment and  of  replacing  knowledge  workers  with  technology.  Downsizing 
affects  individual,  group,  and  corporate  performance  and  therefore 
contains  some  risks  at  each  level.  These  risks  can  be  minimized  by 
careful  consideration  of  the  two  major  aspects  of  downsizing:  techno- 
logical and  organizational.  To  better  understand  the  innovation  occurring 
in  these  two  areas,  the  report  looks  "behind  the  screen"  at  hardware  and 
software  architectures,  "at  the  screen"  at  business  applications,  and 
"beyond  the  screen"  at  management  and  organizational  changes. 

This  report  offers  insights  in  the  areas  described  above  based  on  exten- 
sive secondary  research  as  well  as  primary  research.  A  bibliography  is 
included.  Systems  Architectures  for  Downsizing  also  draws  on  research 
presented  in  a  previous  INPUT  report.  Putting  Downsizing  in  Perspec- 
tive. From  this  broad  background,  INPUT  has  constructed  a  "proper" 
architectural  model  for  a  downsized  network  of  computer  systems,  which 
is  illustrated  in  this  report. 

The  report  contains  130  pages  and  27  exhibits. 
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Introduction 


During  the  research  for  Putting  Downsizing  in  Perspective,  it  was  deter- 
mined that  the  architectural  issues  associated  with  downsizing  ranged 
from  controversies  surrounding  internal  computer  architectures  to  those 
manifested  by  changes  in  management  and  organization  theory.  In  be- 
tween, there  are  complex  technical  and  management  problems  that  have 
challenged  experienced  and  knowledgeable  professionals  for  decades 
without  agreement  on  solution,  or  even  direction.  However,  computer 
vendors  promising  more  technological  "bang  for  the  buck"  from 
downsizing  and  corporate  executives  who  intend  to  eliminate  middle 
management  by  downsizing  are  currently  proceeding  as  if  the  only  thing 
standing  between  more  MIPS  and  leaner,  more  competitive  business 
organizations  is  the  central  IS  department. 

MIPS  merchants  and  corporate  executives  seem  to  share  a  common 
architectural  point  of  view.  It  is  called  "client/server" — a  term  that  didn't 
even  exist  a  couple  of  years  ago.  What  this  seems  to  mean  to  intelligent- 
workstation  vendors  is  that  all  of  the  responsibility  of  "data  manipulation" 
(and  quaUty)  will  be  left  up  to  a  server;  and  "applications,"  which  used  to 
run  on  a  mainframe,  will  now  be  run  on  the  desktop.  What  it  seems  to 
mean  to  corporate  executives  is  that,  with  direct  access  to  data  base  serv- 
ers and  "unlimited"  computer  power,  they  will  no  longer  have  to  depend 
upon  humans  to  analyze,  filter,  interpret,  and  present  this  information  to 
them. 

What  this  means  to  us  is  that  there  are  some  computer  vendors  who  either 
do  not  understand,  or  choose  to  ignore,  the  problems  and  complexity 
involved  in  data  base  management;  and  there  are  some  executives  who  do 
not  understand  the  current  limitations  of  computer  technology  replacing 
knowledge  workers.  Considering  the  fact  that  both  technological  and 
organizational  downsizing  are  proceeding  with  the  intent  of  also  reducing 
information  systems  costs,  these  oversimplified  views  of  an  information 
architecture  appear  to  be  quite  dangerous. 
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A  

Objectives 

The  purpose  of  this  report  is  to  look  at  the  various  layers  of  an  information 
systems  architecture  and  the  risks  associated  with  downsizing.  The  report 
has  the  following  major  objectives: 

•  To  identify  and  explain  the  key  architectural  elements  of  commercial 
data  processing  applications 

•  To  establish  the  importance  and  complexity  of  data  base  management  in 
commercial  information  systems  architectures 

•  To  focus  attention  on  the  necessity  for  integration  of  computer  and 
paper-based  information  systems 

•  To  identify  and  examine  the  competing  architectural  concepts  associated 
with  information  systems  as  they  relate  to  downsizing,  and  to  focus 
attention  on  information  architecture  rather  than  on  tools 

•  To  identify  possible  impacts  of  downsizing  on  individual,  work  unit,  and 
institutional  performance 

•  To  provide  frameworks  for  analysis  of  various  downsizing  innovations 
and  their  potential  benefits  and  consequences 

•  To  integrate  technological  downsizing  with  the  various  management  and 
organizational  initiatives  of  "human"  downsizing — the  purpose  being  to 
take  an  overall  architectural  view  of  the  downsizing  phenomenon 

•  To  present  a  new  architectural  view  of  information  systems  as  they 
relate  to  organization  and  management,  with  emphasis  upon  the  chang- 
ing nature  of  work,  culture,  and  mind- set  in  the  new  downsized  environ- 
ment 

•  To  explore  the  challenges  and  opportunities  presented  by  downsizing  for 
management,  IS,  and  vendors,  with  special  emphasis  upon  IS  manage- 
ment, which  seems  to  be  caught  squarely  in  the  middle  between  expecta- 
tions and  reality 

•  To  reach  some  conclusions  concerning  the  risks  inherent  in  various 
downsizing  approaches  and  to  make  recommendations  for  minimizing 
IS  risk  while  focusing  on  opportunities 
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B  

Scope  and  Methodology 

1.  Methodology 

The  research  for  this  report  was  initiated  during  the  preparation  of  Putting 
Downsizing  in  Perspective.  The  primary  and  secondary  research  for  that 
report  also  provided  the  foundation  for  this  one. 

That  research  also  marked  something  of  a  departure  for  INPUT  reports  in 
that  references  and  a  supporting  bibliography  were  included.  This  does 
not  mean  that  INPUT  is  adopting  a  more  "academic"  format  and  placing 
more  emphasis  upon  secondary  sources.  However,  a  brief  explanation  is 
required. 

During  the  process  of  defining  "downsizing"  it  was  necessary  to  distin- 
guish between  the  technological  downsizing  prompted  primarily  by 
microprocessor  development,  and  organizational  downsizing  prompted  by 
a  complex  set  of  factors  including  new  management  theories,  the  reces- 
sion, the  surprising  decline  of  many  leading  companies  during  the  1980s, 
and  the  failure  of  information  technology  to  provide  competitive  advan- 
tage. The  exact  relationship  between  technological  downsizing  and 
organizational  downsizing  is  not  clear.  However,  there  can  be  no  question 
that  technology  innovations  are  playing  a  major  role  in  determining  the 
global  competitive  environment. 

Although  INPUT  maintains  a  full  program  of  continuing  research  activi- 
ties for  information  technology  innovations,  it  had  no  formal  research 
program  in  the  management  and  organizational  impacts  of  such  innova- 
tions. Therefore,  in  parallel  with  the  primary  research  for  the  downsizing 
study,  an  extensive  literature  search  was  conducted  on  issues  associated 
with  the  management  and  organizational  impacts  of  IT  innovation. 

The  result  was  50  pages  of  models,  lists,  matrices,  processes,  and  rules  for 
encouraging,  discouraging,  managing,  exploiting  and  using  innovations 
from  over  90  publications.  These  publications  were  a  valuable  research 
source  for  this  report.  Some  are  quite  well  known  and  others  are  rather 
obscure.  Some  proved  valuable  in  developing  the  models  used  in  this 
report,  and  these  sources  have  been  appropriately  credited. 

In  addition,  during  the  course  of  this  study,  INPUT  has  been  screening 
specific  organizations  as  downsizing  case  study  companies,  and  approxi- 
mately 20  telephone  and  personal  interviews  were  conducted  with  IS 
management  on  architectural  aspects  of  downsizing  in  their  companies. 
These  case  studies  will  be  fully  documented  in  Case  Studies  in 
Downsizing,  which  will  be  published  in  May  of  this  year.  The  preliminary 
interviews  have  already  proved  valuable  in  the  preparation  of  this  report. 
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Then,  of  course,  downsizing  encompasses  many  of  the  technical  subject 
areas  in  which  INPUT  has  been,  and  is,  conducting  research  on  a  continu- 
ing basis,  such  as  open  systems  and  client/server  architectures. 

2.  Scope 

The  scope  of  this  report  is  exceptionally  broad.  INPUT  has  looked  down 
into  the  microcosm  of  processor  architecture  and  outward  toward  what 
work  will  be  like  "in  the  age  of  the  smart  machine,"  and  has  put  forth  a 
"proper"  architectural  model  for  a  downsized  network  of  computer  sys- 
tems. We  have  identified  and  briefly  analyzed  competing  architectural 
concepts  associated  with  downsizing,  and  have  established  a  general 
strategy  for  risk  reduction.  We  have  not  gotten  embroiled  in  detailed 
discussions  of  the  controversies  surrounding  competing  operating  systems, 
communications  protocols  or  vendor  products,  except  to  acknowledge  the 
realities  of  certain  technologies  in  the  marketplace. 

c  

Related  Reports 

•  Putting  Downsizing  in  Perspective 

*  Case  Studies  in  Downsizing 

•  Client/Server  Applications  and  Markets 

*  Open  Systems  Opportunities 
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Executive  Overview 


A  

Background  and  Methodology 

This  study  is  an  outgrowth  of  Putting  Downsizing  in  Perspective,  a  report 
that  provides  valuable  background  information  for  this  one.  Because  the 
detailed  research  findings  of  Putting  Downsizing  in  Perspective  are  not 
repeated  in  this  report,  it  is  recommended  that  the  reader  become  famiUar 
with  the  earlier  report  in  order  to  achieve  maximum  benefit  from  this  one. 

During  the  process  of  defining  downsizing,  it  was  determined  that  the  term 
is  being  applied  specifically  to  traditional  business  applications  that  are 
currently  running  on  IBM  mainframe  computers.  It  also  became  apparent 
that  technological  downsizing  was  being  accompanied  by  management 
downsizing  of  organizational  structures,  and  that  one  of  the  primary 
objectives  of  technological  downsizing  was  to  reduce  information  systems 
costs. 

Because  the  architecture  of  information  systems  reflects  human  organiza- 
tional structures,  and  information  technology  is  aimed  at  improving  human 
productivity,  it  is  not  logically  inconsistent  to  expect  that  technological 
downsizing  would  be  accompanied  by  downsizing  of  the  human  organiza- 
tional structure.  However,  there  were  several  things  that  disturbed  us 
about  the  relationship  between  the  parallel  downsizing  initiatives  and  their 
anticipated  consequences. 

•  Before  the  term  downsizing  came  into  prominence,  considerable 
downsizing  of  information  systems  technology  had  already  occurred 
during  the  1980s.  Microprocessor-based  workstations  and  personal 
computers  (intelligent  workstations — IWSs)  replaced  minicomputers 
and  mainframes  for  many  engineering  and  office  functions. 
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•  White-collar  productivity  in  the  United  States  did  not  improve  during 
the  1980s,  and  it  has  been  impossible  to  establish  any  positive  correla- 
tion between  investment  in  information  technology  and  enterprise 
performance.  In  fact: 

-  White-collar  workers  are  working  longer  hours  now  than  they  did 
before  they  had  the  personal  productivity  aids  provided  by  their 
personal  computers. 

-  Most  American  business  enterprises  classified  as  "excellent"  in  the 
early  1980s  had  lost  positions  of  leadership  in  international  markets 
by  the  end  of  the  decade,  despite  investing  substantially  more  in 
information  technology  than  did  their  competitors.  [16] 

•  Management's  desire  to  cut  IS  expense  may  be  based  upon  the  fact  that 
investment  in  information  technology  (including  the  personal  computer 
revolution  of  the  1980s)  has  failed  to  achieve  anticipated  results.  It 
seems  obvious  that  the  central  IS  function  is  being  held  responsible  for 
this  failure  (or  at  least  is  considered  part  of  the  problem).  However,  it 
seems  clear  that  the  continued  pursuit  of  technological  downsizing  is 
based  on  the  assumption  that  this  will  somehow  support  organizational 
downsizing  and  lead  to  a  more  competitive  organization. 

In  order  to  better  understand  the  relationship  between  the  innovations  that 
are  occurring  in  both  technological  and  organizational  architectures,  this 
report  established  a  research  metaphor  which  looked  "behind  the  screen" 
at  hardware/software  architectures,  "at  the  screen"  in  terms  of  business 
application  architectures,  and  "beyond  the  screen"  at  the  changes  in 
management  and  organizational  architectures. 

B   

Behind-the-Screen  Architecture 

There  is  a  complex  set  of  information  systems  architectures  behind  the 
screen  of  any  business  system.  The  very  essence  of  downsizing  is  the  shift 
from  a  mainframe,  host-oriented  architecture  to  client/server  architectures 
with  minicomputers  or  IWSs  as  servers  and  IWSs  as  cUents.  Research 
from  input's  previous  study  showed  that  minicomputers  were  top  ranked 
as  distributed  data  base  servers  by  IS  management,  and  INPUT  concurs 
with  that  assessment. 

The  possible  target  platforms  for  downsized  commercial  applications  fall 
into  three  general  categories — proprietary  minicomputers,  RISC/UNIX- 
based  minicomputers  and  IWSs,  and  PS/2-based  LAN  servers.  In  terms  of 
architecture  and  market  acceptance,  one  panicular  system  would  seem  to 
stand  out  above  the  others  as  a  distributed  data  base  server  in  the  commer- 
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cial  environment:  IBM's  AS/400.  Though  IBM  has  not  seen  fit  to  aggres- 
sively market  the  AS/400  for  downsizing  (for  obvious  reasons),  it  must 
receive  attention  as  a  downsizing  platform,  as  shown  in  Exhibit  11- 1.  Its 
advantages  can  be  briefly  summarized  as  follows: 


EXHIBIT  11-1 


Behind-the-Screen  Architecture 
(Target  Applications  and  Platforms) 


Target 
Applications 

Minicomputer 

Target  Platforms 

RISC/UNIX 

PS/2 

Hardware 

System  370/9000 
(CISC) 

AS/400  (HLL) 
Other  (CISC) 

IWSs  &  Minis  (RISC) 

PS/2  (CISC,  MCA) 
Comp,  (CISC,  EISA) 

Systems/ 
Software 
(including  DBMS) 

MVS/ESA 

OS/400  -  SQL 

UNIX  &  UNIX-like 

OS/2  vs.  DOS,  NT 

IMS,  DB2,  CICS 

Various  Proprietary 

C+,  Various  relational 

Various  relational-like 
productivity  tools 

Commercial 
Applications 
Software 

COBOL 

Programming 

"Investment" 

RPG-COBOL-pkgd. 

Limited 

Most  "applications" 
are  tools,  few 
industrial  strength 

C0B0L-4GLS 
Same  packages 

Data  Bases 

IMS,  DB2 

OS/400-manv 

Few  installed 

Few  real  data  bases, 
many  spreadsheets 

Various 

Business 
Systems 

IBM  oriented" 

S/3X,  AS/400 
predominate 

Extremely  limited 

Office  productivity 
Few  mainstream 
applications 

DEC,  HP,  DG 

Innovation  Phase 

Consequences: 

complex, 

expensive 

AS/400:  extensive  & 

diffused; 

quality  award 

Development, 
commercialization, 
limited  diffusion, 
uncertain 
consequences 

Development, 
commercialization, 
limited  diffusion, 
uncertain 
consequences 

•  Against  mainframe  hosts  its  tightly  integrated  hardware/software  archi- 
tecture, single-level  addressing,  superior  connectivity,  and  ease  of  use 
provide  clear-cut  advantages  in  terms  of  installability  and  usability.  This 
results  in  substantially  lower  support  costs  for  systems  programmers, 
operators  and  data  base  administrators.  IBM  recendy  stated  publicly 
that  such  support  costs  on  the  AS/400  are  estimated  to  be  one-fifth  those 
for  mainframes  used  for  comparable  size  data  bases  and  attached  work- 
stations. 


UIDSA 


©  1992  by  INPUT.  Reproduction  Prohibited. 


n-3 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


•  Against  other  proprietary  minicomputers,  the  AS/400  has  dominated  the 
commercial  midrange  market  since  it  was  announced  nearly  four  years 
ago.  Other  minicomputer  manufacturers  have  embraced  UNIX  and 
"open  systems"  to  attack  the  AS/400.  Four  years  ago,  DEC  was  stating 
that  the  System/3X  (the  AS/400  predecessor)  had  only  a  "niche  market" 
and  that  UNIX  was  "snake  oil."  Today,  the  AS/400  exceeds  DEC's  total 
sales,  and  DEC  is  rubbing  on  the  "snake  oil"  to  protect  its  market  share. 
Wang  was  a  leader  in  departmental  computing  and  image  processing 
five  years  ago,  and  it  is  now  selling  AS/400s  in  an  effort  to  protect  its 
image  processing  market. 

•  Regardless  of  what  one  reads  in  the  trade  press,  RISC/UNIX  systems  are 
not  penetrating  the  commercial  market  in  significant  numbers  as  either 
midrange  systems  or  as  IWSs.  Despite  the  development  by  major 
vendors  of  "UNIX-like"  systems  in  an  effort  to  improve  the  basic  UNIX 
kemel(s)  for  the  commercial  market,  UNIX  still  has  a  long  way  to  go  as 
a  transaction  processor  or  distributed  data  base  server  in  a  client/server 
architecture.  Even  vendors  who  have  embraced  UNIX  and  open  systems 
are  finding  that  their  proprietary  systems  continue  to  sell  well.  Against 
the  AS/400  as  a  downsizing  platform,  there  is  just  no  contest  where  data 
base  integrity,  synchronization  and  security  are  concerned — and  those 
are  precisely  the  concerns  of  IS  management  in  a  downsizing  environ- 
ment. 

•  The  PS/2,  and  compatibles,  cannot  be  taken  seriously  as  distributed  data 
base  servers  for  downsized  mainframe  applications  at  this  time.  The  PS/ 
2's  basic  hardware/software  architecture  just  isn't  up  to  the  job. 

-  Customers  (and  software  vendors)  are  still  struggling  with  how  to 
make  effective  use  of  contiguous,  extended,  and  expanded  memory 
under  DOS  5.0. 

-  Most  PC  "applications"  continue  to  be  software  tools,  and  word 
processing  and  desktop  publishing  remain  the  most  prominant  busi- 
ness applications. 

-  Most  personal  "data  bases"  on  personal  computers  are  stored  in 
spreadsheet  files,  and  standard  error  recovery  consists  of  hitting  the 
reset  button. 

-  Shrinkwrapped  business  applications  are  not  industrial  strength,  and 
the  next  "Downsizing — International  Conference  &  Exposition"  will 
feature  a  paper  on  "The  Danger  of  the  Shrinkwrap  Fallacy." 

-  An  operating  system  war  is  still  going  on,  and  while  OS/2  EE  holds 
promise  of  being  an  industrial-strength  operating  system,  there  is 
currently  no  proof  that  it  is  robust  enough  to  serve  as  a  distributed  data 
base  server  for  downsized  commercial  applications. 
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-  The  recent  Michelangelo  virus  scare  is  a  good  example  of  the  maturity 
of  the  personal  computer  industry:  if  you  can't  fix  it  with  the  reset 
button,  push  the  panic  button. 

It  is  obvious  that  both  RISC/UNIX  and  personal  computer  hardware/ 
software  are  still  undergoing  development  and  commercialization  for  the 
business  systems  market.  Both  technologies  have  yet  to  be  widely  dif- 
fused in  the  commercial  data  processing  market.  Every  month  that  passes, 
over  $1  billion  worth  of  AS/400s  go  directly  into  that  market.  When 
looking  for  data  in  the  downsized  environment,  it  will  be  necessary  to 
interface  with  AS/400s,  because  they  have  already  seized  the  high  ground 
on  what  has  never  been  a  level  playing  field. 

Any  objective  report  card  comparing  the  architectures  and  market  accep- 
tance of  potential  downsizing  platforms  as  distributed  data  base  servers  in 
the  commercial  market  would  give  the  AS/400  a  clear  advantage  over  its 
competitors.  The  Malcolm  Baldridge  Award  for  quality  that  was  given  to 
the  AS/400  confirms  that  it  is  a  superior  hardware/software  product  in  the 
real  world. 


c  

On-the-Screen  Architecture 


The  reason  we  feel  that  minicomputer  distributed  data  base  servers  are  the 
most  important  component  in  the  downsized  application  network  is  be- 
cause the  biggest  challenge  for  the  1990s  is  going  to  be  the  integration  of 
downsizing  applications  with  paper-oriented  systems  at  the  work  unit 
level.  The  user  sitting  at  the  screen  should  have  access  to  data  and  infor- 
mation regardless  of  its  medium  of  origin.  Voice,  image  and  knowledge 
rules  will  all  become  data  to  be  distributed  in  the  1990s. 

The  AS/400  provides  the  necessary  architecture  to  take  the  broadest 
possible  view  of  data  by  du-ectly  addressing  28 1  trillion  bytes  of  storage 
(48-bit  addressing).  However,  it  has  been  stated  that  the  AS/400  is 
"implemented  with  a  software  and  hardware  architecture  that  could  ac- 
commodate up  to  64-bit  addressing...."  and  that  "this  architecture  accom- 
modates the  needs  of  advanced  applications  such  as  voice,  image  and 
artificial  intelligence."  [21]  What  this  means  is  that  the  AS/400  will  be 
able  to  directly  address  18  quintillion  bytes  of  storage — that  is  about  3 
billion  bytes  for  every  human  being  on  the  face  of  the  earth.  It  provides 
the  broadest  possible  window  on  the  electronic  world  that  supports  the 
person  at  the  screen. 
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Does  this  mean  that  the  AS/4(X)  is  the  solution  to  all  of  the  commercial 
data  processing  world's  problems?  No;  a  proper  hierarchy  of  mainframes, 
minicomputers  and  IWSs  will  exist  well  past  the  millennium,  and  there  is 
even  good  reason  for  co-existence  with  the  RISC/UNIX  world.  The 
proper  network  architecture  for  the  downsized  world  of  the  1990s  is 
depicted  in  Exhibit  11-2. 


EXHIBIT  11-2 


Magnetic 
&  Optical 


Downsized  Applications  and  Functions 


Superservers 
Magnetic  &  Optical 


1 .  Transaction  reservoirs 

2.  Archival  data  warehouses 

3.  Backup  for  distributed  applications 

4.  Enterprise  repository 


Gateway  to  and  from  Outside  Work 


1 .  Distributed  data  base  management 

2.  Network  management 

3.  Integration  of  business  systems 

4.  Object  management 

5.  Connectivity 


Any  Topology 


RISC 
IWS 


Downsized  Functions 


lllillllllllllllllllllllllllll 

— BB 

1 .  Compute  intensive 

2.  Knowledge-based 

3.  High-resolution  I/O  driver 


1.  Data  capture/editing 

2.  Report  preparation 

3.  Personal  data  bases 

4.  Personal  productivity 

5.  Continuous  Learning 


1 .  Automated  processes 

2.  Secure  processes 

3.  Data  entry  and  editing 

4.  Information  retrieval 


•  There  will  be  a  continuing  role  for  mainframe  superservers  regardless  of 
how  many  applications  are  downsized. 

•  Clients  of  many  types  will  perform  essential  functions: 
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-  RISC  IWSs  will  become  increasingly  important  as  business  applica- 
tions become  more  compute  intensive  at  the  human/machine  dyad. 

-  Personal  computers  will  expand  their  role  of  empowering  information 
and  knowledge  workers  with  both  computer  power  and  ready  access 
to  increasingly  complex  data  objects. 

-  Diskless  IWSs  will  provide  cost-effective  automation  of  office  pro- 
cesses where  work  simplification  and  a  restricted  view  of  data  are 
desirable. 

•  However,  the  centerpiece  of  what  is  going  on  at  the  screen  is  the  mini- 
computer distributed  data  base  server  that  provides  the  essential  data 
base  and  network  management  functions  on  an  operational  basis. 

D  

Beyond-the-Screen  Architecture 

IS  management  has  traditionally  concentrated  on  the  architecture  of 
information  systems  behind  the  screen  and  at  the  screen;  frequentiy,  at  the 
expense  of  what  is  going  on  beyond  the  screen  in  terms  of  the  human 
architectures  associated  with  management  and  organization  at  the  working 
level.  This  has  resulted  in  the  IS  department  being  identified  with  the 
corporate  planning  and  control  functions — a  mere  extension  of  the  corpo- 
rate controller. 

This  highly  centralized  power  structure  has  been  supported  by  mainframe 
computer  technology  and  corporate  data  bases,  and  it  is  difficult  to  deter- 
mine which  is  cause  and  which  is  effect.  However,  during  the  PC  revolu- 
tion of  the  1980s,  computer  power  was  distributed  to  operating  depart- 
ments. There  were  increased  demands  for  data  from  operating  depart- 
ments, but  operating  management  still  did  not  have  ready  access  to  corpo- 
rate data  bases.  This  resulted  in  highly  centralized  financial  planning  and 
control  systems  coming  under  increasing  attack  from  operating  manage- 
ment as  being  unresponsive  to  their  demands  (and  needs)  for  data  and 
information  necessary  to  run  their  day-to-day  business.  Then,  as  once- 
dominant  Western  enterprises  started  to  lose  competitive  advantage  to 
more  flexible  and  responsive  organizations,  enlightened  corporate  leaders 
began  to  take  action  to  change  the  human  architecture  of  their  companies. 

This  was  normally  accomplished  by  organizational  downsizing  in  terms 
of: 

•  Drastically  reduced  corporate  planning  organizations,  loosening  of  some 
traditional  corporate  financial  controls,  and  delegating  some  responsibil- 
ity to  operating  units 
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•  Drastically  reduced  levels  of  middle  management,  with  accompanying 
increases  in  span  of  control 

Once  again,  it  is  difficult  to  know  what  is  cause  and  effect  between  the 
technological  downsizing  that  was  occurring  and  the  management  initia- 
tives that  were  being  taken.  However,  there  is  no  question  that  the  two 
downsizing  initiatives  are  co-dependent,  and  that  both  trends  are  accelerat- 
ing in  the  1990s.  Both  technological  and  organizational  downsizing 
depend  upon: 

•  Availability  and  ready  access  to  sources  of  high-quality  data  and  infor- 
mation 

•  The  capture  of  human  knowledge  at  the  human/machine  dyad,  and  the 
shifting  of  some  human  intellectual  activities  to  the  artificial  side  of  the 
interface 

•  Upgrading  human  knowledge  through  continual  learning  by  working 
with  the  "intelligent  artifact"  (or  corporate  data  base) 

This  synergistic  relationship  between  information  technology  and  humans 
will  lead  to  drastically  new  organization  structures  and  management 
responsibilities. 

Research  for  this  study  resulted  in  the  adoption  of  a  "concentric  ring" 
management  architecture  that  was  defined  by  Shoshana  Zuboff  in  her 
book:  In  the  Age  of  the  Smart  Machine  (The  Future  of  Work  and  Power) 
[15].  Although  Dr.  Zuboff  found  it  necessary  to  coin  some  dreadful  new 
terms  for  her  vision  of  the  future,  her  book  does  place  the  technological 
and  human  architectures  in  perspective  and  helps  define  the  role  of  IS 
management  as  downsizing  proceeds  (see  Exhibit  II-3). 

•  We  have  superimposed  a  distributed  network  of  superservers  and  distrib- 
uted data  base  servers  on  Zuboff  s  "core  electronic  data  base."  This 
more  accurately  depicts  the  downsized  environment  and  the  breaking  up 
of  corporate  control  and  data  bases. 

•  This  core  electronic  data  base  is  then  surrounded  with  four  concentric 
rings  of  management  with  the  following  responsibilities: 

-  The  "intellective"  skill  development  (or  continuous  leaming)  of 
workers  who  interact  with  the  core  electronic  data  base.  Since  every- 
one will  interact  with  the  core  data  base,  such  intellective  skill  devel- 
opment will  involve  everyone  from  entry-level  employees  to  the 
highest  corporate  executives. 


©  1992  by  INPUT.  Reproduction  Prohibited. 


■UIDSA 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


EXHIBIT  11-3 


Organizational  Architecture 


1 .  Intellective  skill  development 

2.  Technology  development 

3.  Strategy  formulation 

4.  Social  system  development 


-  Information  technology  identification  and  development  necessary  to 
assure  the  maintenance  and  expansion  of  the  core  electronic  data  base, 
which  represents  the  accumulated  experience  and  knowledge  of  the 
enterprise 
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=  Strategy  formulation  for  the  enterprise  based  on  interaction  between 
humans  and  the  "intellective  skill  base"  (Zuboff's  term)  or  "intelligent 
artifact"  (Simon's  term) 

-  The  establishment  of  a  social  system  that  encourages  the  continuing 
improvement  of  the  "living  system"  that  is  the  total  organization  (both 
artificial  and  human) 

It  is  input's  opinion  that  both  technological  and  m^anagement 
downsizing  are  moving  toward  such  an  organizational  architecture,  and 
that  qualified  IS  personnel  have  an  important  role  to  play,  not  only  behind 
and  at  the  screens  that  serve  as  windows  on  the  "intellective  skill  base," 
but  in  positions  of  leadership  in  the  first  two  rings  of  responsibility  ("intel- 
lective" skill  development  and  technology  development).  Because  the 
other  two  levels  of  management  are  dependent  on  the  core  electronic  data 
base,  it  would  appear  that  future  executives  will  also  be  drawn  from 
among  those  most  familiar  with  the  "intelligent  artifact." 

The  ramifications  of  "eliminating"  middle  management  and  empowering 
workers  closest  to  the  electronic  data  base  would  seem  to  be  quite  clear. 
There  will  be  an  aging  executive  elite  and  an  emerging  technological  elite, 
and  no  established  career  paths  for  other  operational  personnel.  The 
consequences  of  such  a  strategy,  while  not  clear,  would  seem  to  argue  for 
an  increasingly  important  role  for  those  with  information  technology 
expertise. 

However,  the  degree  of  IS  involvement  in  the  downsizing  of  the  1990s 
will  depend  upon  the  mind- set  of  current  executives.  There  are  already 
reports  of  CIOs  who  have  "downsized"  themselves  out  of  their  positions. 
This  can  obviously  occur  if  the  primary  purpose  of  technological 
downsizing  is  literally  to  cut  IS  costs.  It  would  seem  to  be  extremely 
short-sighted  to  downgrade  (or  disperse)  the  IS  function  as  part  of  the 
downsizing  process  for  the  following  reasons: 

•  The  IS  function  has  a  major  role  to  play  in  making  technological 
downsizing  successful,  and  it  is  unreasonable  to  expect  very  many  IS 
employees  to  downsize  themselves  out  of  jobs. 

•  A  weakened  IS  function,  and  technological  base,  will  have  an  adverse, 
long-term  impact  on  the  management  initiatives  directed  toward  organi- 
zational downsizing. 

Under  any  circumstances,  IS  management  is  presented  with  a  significant 
challenge  to  both  cut  costs  and  preserve  and  expand  the  "intellective"  skill 
base  of  the  organization.  Though  this  may  be  extremely  difficult  to 
accomplish,  the  rewards  for  those  who  are  successful  will  be  commensu- 
rate with  the  difficulty. 
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E   

Conclusions  and  Recommendations 


Exhibit  11-4  contains  a  brief  summary  of  the  major  conclusions  and  recom- 
mendations. 
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Conclusions  and  Recommendations 


•  !S  management  has  frequently  been  isolated  from 
the  mainstream  of  the  corporation  by  being 
associated  with  corporate  planning  and  control 
functions. 

•  Both  technological  and  organizational  downsizing 
will  assure  that  IS  management  becomes  more 
actively  involved  in  the  mainstream  of  the  company. 

•  IS  management  is  being  placed  in  a  difficult 
position  by  being  asked  to  both  cut  costs  and  to 
assure  that  technological  and  organizational 
downsizing  efforts  are  successful — this  despite  the 
fact  that  IS  is  identified  as  being  part  of  the 
problem. 

•  INPUT  believes  that  companies  that  weaken,  or 
fragment,  the  central  IS  function  will  place  their 
organizations  in  an  extremely  vulnerable  position. 

•  IS'  primary  objective  during  downsizing  should  be  to 
minimize  the  risks  associated  with  unproven 
hardware/software  technologies  (this  may  not  be  a 
popular  position). 

•  INPUT  believes  that  the  architecture  depicted  in 
Exhibit  11-2  and  employing  ASMOOs  as  distributed 
data  base  servers  will  be  the  safest  and  the  most 
cost-effective  architecture  for  downsizing. 

•  INPUT  believes  that  the  concentric  ring  model  is  a 
good  representation  of  where  technological  and 
organizational  downsizing  may  lead,  and  believes 
that  IS  has  increased  leadership  responsibility  in 
the  resulting  organization. 

•  Re-engineering  of  applications  is  necessary  during 
downsizing  in  order  to  move  toward  management 
downsizing  objectives.  An  improved  systems 
development  environment  will  be  the  result  of  the 
new  organizational  structure. 
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Conclusions  and  Recommendations 


•  INPUT  recommends  that  IS  management  assume 
a  leadership  role  while  supporting  both 
technological  and  management  downsizing 
initiatives. 

•  Commitment  to  quality  should  be  the  primary 
emphasis  of  all  downsizing  efforts. 

•  Consider  and  evaluate  all  new  (or  unfamiliar) 
hardware/software  technologies  and  select 
downsizing  platforms  based  on  their  long-term 
applicability  to  your  particular  organization. 

•  Evaluate  the  need  for  distributed  data  bases  from  a 
strategic  perspective.  There  may  be  simpler 
architectures  that  could  satisfy  a  high  percentage 
of  your  needs. 

•  Develop  a  long-range  information  architecture  and 
technological  plan  for  your  organization  with  the 
agreement  and  cooperation  of  both  corporate  and 
operating  management. 

•  Develop  a  downsizing  plan  based  upon  this 
architecture  and  technological  scenario  with 
special  emphasis  upon  anticipated  benefits  and 
consequences. 

•  Assume  leadership  responsibilities  for  "intellective" 
skill  and  technology  development  within  your 
current  organization,  but  be  prepared  to  share 
these  responsibilities  with  operating  management 
in  the  downsized  environment. 
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Downsizing  and 

Hardware/Software  Architectures 

During  research  for  INPUT'S  earlier  report  on  downsizing  {Putting 
Downsizing  in  Perspective),  it  was  determined  that  "upsizing"  was  pro- 
ceeding in  parallel  with  downsizing,  and  that  "rightsizing"  should  really 
be  the  objective.  However,  the  rapid  advances  in  microprocessor  technol- 
ogy, and  the  resistance  of  mainframe  commercial  applications  to  change 
have  resulted  in  a  price/performance  discontinuity  between  the  two  that 
will  make  downsizing  the  predominant  architectural  trend  of  the  1990s. 

It  is  important  to  understand  that  downsizing  is  not  just  another  fad  in  the 
computer  industry.  It  represents  a  fundamental  shift  in  information  sys- 
tems architecture  at  all  levels — from  hardware  design  to  presentation 
media.  In  some  ways,  there  are  striking  similarities  between  the 
downsizing  phenomenon  and  the  shift  from  unit  record  equipment  to 
computers  in  the  1950s.  This  is  ironic  because  many  of  the  commercial  . 
applications  that  may  be  downsized  still  bear  the  stamp  of  their  punch- 
card  heritage;  and,  as  we  shall  see,  this  will  be  passed  on  to  the  next 
generation  of  commercial  systems  in  a  rather  surprising  way. 

The  metaphor  we  have  adopted  for  this  architectural  analysis  is  the 
graphic  user  interface  (GUI),  which  is  currently  being  promoted  as  the 
solution  to  all  of  the  data  processing  world's  problems.  Theoretically,  the 
user  at  the  GUI  should  not  have  to  be  concerned  about  the  underlying 
hardware/software  architecture  behind  the  screen,  or  even  where  data 
resides.  The  basic  premise  of  this  report  is  that  someone  (and  we  assume 
that  someone  is  IS  management)  must  be  concerned  not  only  with  what  is 
happening  behind  the  screen,  but  what  is  happening  beyond  the  screen  in 
terms  of  the  "  human  architectures"  of  organizational  structures  and 
processes  that  currently  exist  in  the  real  world  outside  the  computer. 

We  will  start  behind  the  screen  with  the  computer  hardware  itself. 
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A  

Hardware  Platforms 

Over  15  years  ago,  INPUT  decided  to  classify  mainframes,  minicomput- 
ers, and  microprocessor-based  "intelligent  terminals"  based  on  their  price, 
and  how  they  fit  within  the  organization,  rather  than  on  their  then-prevail- 
ing 32-,  16-,  and  8-bit  architectures.  This  decision  was  based  on  the  fact 
that  internal  architectures  and  performance  would  change,  but  the  limits 
on  investment  in  computer  technology  at  the  individual  and  work-unit 
levels  would  remain  relatively  constant.  Therefore  it  was  decided  that 
computers  costing  less  than  $20,000  would  be  classified  as  inteUigent 
terminals  (or  workstations),  and  those  costing  less  than  $200,000  would  be 
classified  as  minicomputers,  and  everything  over  that  would  be  classified 
as  mainframes.  These  classifications  continue  to  prove  useful  despite 
several  orders  of  magnitude  of  improvement  in  price/performance  at  the 
lower  levels  (see  Exhibit  III- 1 ). 
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EXHIBIT  III-1 


Processor  Architectural  Definitions 
and  Attribute  Evaluations 


Cost 

Terms 

#1  Attributes 

Mainframes 

>$200,000 

Host 

Superserver 

Security 
Connectivity 

Commercial  applications 
H/S  reliability 
Data  base  management 
NetworK  management 
Vendor  support 
Applications  software 
H/S  architecture 
Complexity 

Minicomputers 

>$20,000 

Distributed  processor 
Departmental  processor 
Midrange  systems 
Small  business  system 
Server 

Distributed  data  server 

*Rpn  nnn  -u  or  - 

II  llC/III^Cl  11  WUI  INolClUUI  1 

Engineering  workstation 
Server 

Client/requester 

Q^iontifi/"*  annli^atinnc 

OOICIILIIIW  Cl|J|JMLrClUUI  lo 

IWS 

<$20,000 

Personal  computer 
rrogrammauie  worKsiaiion 
Intelligent  workstation 
Intelligent  terminal 
PC  LAN  (client/server) 
Client/requester 

Cost  effective 
easy  TO  program 
Open  architecture 
"Bargain" 
Easy  to  use 
Easy  to  operate 

Other 

Microprocessors 

<2,000 
1 

200 
1 

20 

Application-specific 
Integrated  circuits 
Embedded  processors 

UIDSA 


©  1992  by  INPUT.  Reproduction  Prohibited. 


ni-3 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


When  INPUT  conducted  the  research  for  Putting  Downsizing  in  Perspec- 
tive it  used  the  terms  mainframe,  minicomputer,  RISC  and  PC;  and  used 
examples  from  the  IBM  product  line. 

Let's  examine  each  part  of  that  hierarchy. 

1.  Mainframes 

The  $200,000  cost  threshold  for  mainframes  is  for  the  processor  alone, 
and  obviously  mainframe  systems  as  we  have  come  to  know  them  usually 
cost  considerably  more  than  this  lower  limit.  One  of  the  reasons  there  is 
usually  a  "giant  step"  associated  with  crossing  the  line  into  mainframe 
territory  is  because  of  IBM  operating  systems.  This  is  also  the  reason  that 
large  IBM  mainframes  are  such  an  attractive  target  for  downsizing. 

Mainframes  serve  a  large  number  of  users  and  their  primary  strength  is  the 
ability  to  move  and  store  a  lot  of  data.  This  is  facilitated  by  a  complex  set 
of  I/O  channels  that  are,  in  effect,  reduced  instruction  set  computers  that 
operate  independently  of  the  central  processing  unit.  Therefore,  using 
mainframe  central  processor  MIPS  a  a  measure  of  performance  against 
other  architectures  is  meaningless. 

Though  mainframes  are  increasingly  incorporating  multiple  processors  to 
boost  performance,  they  remain  "von  Neumann  machines"  that  treat 
instructions  and  data  in  a  similar  fashion.  This  means  that  they  funnel  data 
back  and  forth  between  storage  and  the  processor(s)  one  word  at  a  time. 
This  has  been  referred  to  as  the  "von  Neumann  bottleneck"  by  advocates 
of  more  esoteric  architectures,  but  large  mainframes  are  not  so  much 
concerned  with  compute  speed  as  they  are  with  moving,  arranging,  storing 
and  retrieving  data.  Even  supercomputers  find  it  convenient  to  have  a 
mainframe  front  end  to  handle  data  manipulation. 

Mainfi^ame  hosts  have  struggled  to  keep  up  with  the  processing  demands 
made  on  them  for  both  transaction  and  batch  processing  of  large  data 
bases.  In  the  mid-1980s,  it  was  reported  that  large  commercial  installa- 
tions devoted  between  15%  and  30%  of  their  usable  CPU  cycles  and  I/O 
activity  to  sorting.  [1]  This  is  quite  remarkable,  because  it  exceeds  on 
either  end  the  amount  of  time  spent  by  major  IBM  installations  on  sorting 
in  a  serial  batch  environment  in  the  early  1960s  (20%  to  25%  of  wall  clock 
time).  Despite  advances  in  DASD,  multiprogramming,  data  base  manage- 
ment systems,  memory  size,  on-line  transaction  processing,  and  sorting 
algorithms  themselves,  these  large  installations  still  spend  approximately 
the  same  amount  of  time  sorting. 

For  some  reason,  the  reality  and  importance  of  large-scale  data  manipula- 
tion (of  which  sorting  appears  to  remain  a  major  factor)  seems  to  be 
difficult  for  many  computer  scientists  and  hardware/software  engineers  to 
grasp.  The  architects  of  the  IBM  System/360  refused  to  incorporate 
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indirect  addressing  in  the  architecture,  and  IBM's  early  research  on  local- 
ity of  reference  in  virtual  storage  systems  failed  to  take  sorting  into  con- 
sideration. Large  IBM  mainframes  continue  to  struggle  under  the  burden 
of  these  oversights. 

However,  despite  the  fact  that  the  sacred  IBM  mainframe  architecture  is 
not  especially  well  suited  for  either  scientific  or  commercial  environments, 
it  has  provided  the  balance  necessary  for  the  management  of  large  data 
bases.  As  downsizing  proceeds  in  the  1990s,  the  role  of  the  large  main- 
frame as  a  "superserver"  will  remain  reasonably  secure.  IS  management 
recognizes  this  fact.  Although  INPUT'S  research  showed  that  there  will 
be  a  significant  shift  away  from  mainframes  toward  more  cost-effective 
platforms  in  the  1990s,  few  respondents  felt  that  mainframes  were  going 
to  disappear. 

In  addition,  IS  management  ranked  mainframes  first  (above  minicomput- 
ers, RISC  systems,  and  PCs)  on  the  following  attributes  (see  Exhibit 
in-1): 

•  Security 

•  Connectivity 

•  Best  for  commercial  applications 

•  Hardware/software  reliability 

•  Network  management 

•  Vendor  support 

•  Applications  software  availability 

•  Hardware/software  architecture 

These  are  practically  all  of  the  attributes  that  are  important  for  commercial 
applications,  and  the  only  drawback  is  that  mainframes  were  also  ranked 
first  in  terms  of  complexity.  As  downsizing  proceeds,  an  important 
consideration  will  be  how  much  of  this  mainframe  complexity  is  necessary 
to  make  effective  use  of  information  technology,  and  how  much  cost  can 
be  justified  based  on  the  strengths  of  mainframe  systems. 

2.  Minicomputers 

Minicomputers  have  been  around  for  several  decades  and  have  offered 
attractive  alternatives  to  mainframe  computers  for  specific  applications  by 
employing  simpler  technology,  more  specialized  systems  software,  and 
better  price/performance.  INPUT'S  price  range  of  $20,000  to  $200,000 
for  minicomputers  has  held  up  remarkably  well  in  terms  of  functional  use 
despite  enormous  increases  in  processing  power,  which  have  tended  to 
make  minicomputers  an  ever-increasing  threat  to  offload  mainframes. 

IBM  has  been  exceptionally  adroit  at  resisting  the  advance  of  minicomput- 
ers into  conventional  mainframe  environments.  Historically,  this  was 
done  by  announcing  a  variety  of  "solutions"  with  various  architectural 
characteristics  and  priced  to  compete  on  a  selected  basis  in  the  minicom- 
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puter  market.  The  purpose  of  this  architectural  and  market  fragmentation 
was  to  limit  the  offloading  (downsizing)  of  large  IBM  mainframes;  this 
strategy  was  highly  successful  over  an  extended  period  of  time. 

Among  the  "minicomputers"  that  were  used  in  this  strategy  were: 

•  The  Series/1,  which  was  a  legitimate  minicomputer  but  supported 
primarily  for  process  control  and  other  real-time  applications 

•  The  3790/8100  cluster  controllers,  which  were  used  for  controlling 
dumb  terminals.  (The  8100,  though  promoted  as  a  distributed  process- 
ing engine,  remained  underpowered  and  the  DPPX  operating  system 
placed  enormous  demands  upon  the  customer  who  really  wanted  to 
offload  major  functions  from  mainframes.) 

•  The  System/3. .36  series  of  small  business  computers  started  as  the  last 
gasp  of  punch-card=oriented  technology  and  was  directed  primarily 
toward  the  first-time  computer  user. 

•  The  Systerri/38  was  originally  designed  as  a  replacement  architecture  for 
the  System/360/370  machines.  It  was  called  "Future  System"  (FS)  and 
featured  tight  integration  of  hardware  and  software.  After  a  half  billion 
dollars  of  development  expense  and  some  technical  problems  with  the 
implementation  of  the  complex  architecture,  it  was  decided  that  IBM 
customers  had  "too  much  investment  in  programming"  on  their  old 
mainframes  to  pull  the  platform  out  from  under  them.  So  the  System/38 
was  announced  and  remained  a  mystery  to  the  IBM  sales  force,  custom- 
ers and  competition — practically  everyone  except  those  interested  in  the 
innards  of  computer  architecture  and  the  hardware/software  interface. 

•  The  43XX  and  9370  line  of  midrange  systems  were  downward  exten- 
sions of  the  360/370  line  of  computers,  with  engines  too  weak  to  carry 
the  burden  of  IBM  mainframe  operating  systems  but  designed  to  provide 
a  bridge  at  the  high  end  in  order  to  make  the  giant  step  necessary  to  get 
into  the  IBM  mainstream.  These  systems  were  supported  and  even 
promoted  as  distributed  processing  engines  by  IBM,  but  with  minimal 
success.  It  is  possible  that  the  original  code  name  of  "Hydra"  for  IBM's 
distributed  processing  suppon  had  something  to  do  with  it.  (For  those 
unfamiliar  with  Greek  mythology,  Hydra  was  a  many-headed  water 
serpent  that  grew  two  new  heads  for  every  one  that  was  cut  off.)  Cer- 
tainly, the  vision  of  chopping  off  a  mainframe  and  having  two  grow 
back  was  not  far  from  IBM's  mind  when  it  code-named  the  project,  but 
it  is  probable  that  customers  sensed  the  strategy  also. 

•  In  addition  to  all  of  these  minicomputer  "solutions,"  IBM  also  had 
clustered  word  processing  systems  that  were  competing  in  the  office 
environment  against  depanmental  processors  from  compedtive  vendors 
such  as  Wang. 
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This  confusion  at  the  work  unit  (office)  level  became  especially  trouble- 
some after  the  PC  was  announced  and  it  became  obvious  that  a  great  deal 
of  work  from  both  mainframes  and  minicomputers  could  potentially 
migrate  to  the  desktop.  The  resulting  chaos  at  the  minicomputer  level  was 
the  primary  reason  that  IBM  announced  its  Systems  Applications  Archi- 
tecture; and,  subsequently,  the  AS/400  as  the  first  real  SAA  machine.  The 
AS/400  combined  the  architecture  of  the  System/38  and  the  ease  of  use  of 
the  System/36,  and  it  has  been  a  phenomenal  success  in  the  marketplace. 
A  more  detailed  analysis  of  its  architecture  will  be  presented  in  the  next 
section  of  this  report. 

We  have  gone  through  this  rather  lengthy  history  of  IBM's  minicomputer 
strategy  because  it  has  shaped  the  downsizing  competitive  environment, 
and  because  we  believe  that  servers  in  the  minicomputer  price  range  hold 
the  key  to  downsizing.  Our  research  for  Putting  Downsizing  in  Perspec- 
tive revealed  that  IS  management  rated  minicomputers  as  the  best  distrib- 
uted data  base  servers.  We  agree  with  that  assessment,  and  the  hardware/ 
software  architecture  of  those  distributed  data  base  servers  is  going  to  be 
an  exceptionally  important  consideration  in  selecting  appropriate 
downsizing  applications  and  platforms. 

3.  RISC  Workstations/Servers 

RISC  technology  has  been  isolated  as  a  separate  platform  because  of 
marketplace  perception  and  because  this  is  a  report  on  architecture. 
input's  $20,000  razor  splits  RISC  systems  into  intelligent  workstations 
(IWSs)  on  one  side  and  minicomputers  (servers)  on  the  other  side.  (It 
should  be  pointed  out  that  direct  access  storage  is  included  in  the  cost  of 
RISC  systems  and  PCs,  but  only  processor  and  channel  costs  are  included 
in  the  costs  for  mainframes  and  minicomputers.) 

RISC  architecture  is  conceptually  an  old  idea,  and  merely  the  latest  mani- 
festation of  the  continuing  battle  between  hardware/firmware/software 
implementation  of  computer  systems.  John  Cocke,  the  IBM  inventor  of 
RISC,  was  a  "wild  duck"  who  refused  to  fly  in  formation  with  the  other 
System/360  architects  in  the  1960s;  several  computers  prior  to  that  time 
(such  as  the  RCA  601)  were  built  on  processors  featuring  "elementary 
operations."  RISC  architecture  will  be  discussed  in  somewhat  more  detail 
in  the  next  section  of  this  report,  but  the  following  characteristics  are 
fundamental: 

•  RISC  architecture  requires  the  execution  of  more  rather  than  fewer 
instructions  to  accomplish  the  same  task  (regardless  of  what  some  trade 
press  pundits  have  had  to  say  on  the  subject). 

•  It  is  especially  fast  at  binary  arithmetic,  but  isn't  especiallygood  for 
either  floating-point  or  decimal  arithmetic.  This  means  it  is  great  for 
driving  high-resolution  displays  with  complex  graphics,  and  for  image 
processing,  but  frequently  requires  a  coprocessor  for  floating  point. 
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•  The  reduced  instruction  set  also  places  more  burden  on  systems  pro- 
grammers who  must  develop  efficient  compilers  to  handle  character- 
oriented  operations  such  as  decimal  arithmetic;  and  for  building 
operating  systems  that  must  handle  I/O. 

•  There  has  always  been  a  tendency  on  the  part  of  engineers  to  drive  down 
costs  by  leaving  certain  functions  to  "programming."  The  track  record 
on  large  systems  programming  projects  raises  serious  questions  concem- 
ing  the  wisdom  of  such  design  trade-offs. 

IS  management  ranked  RISC  systems  as  best  for  scientific  applications, 
but  generally  tended  to  favor  PCs  as  the  platforms  of  choice  for 
downsizing.  Vendors,  on  the  other  hand,  were  more  favorably  disposed 
toward  RISC  for  a  wide  variety  of  applications. 

4.  Intelligent  Workstations 

As  can  be  seen  in  Exhibit  III-l,  there  are  considerably  more  terms  than 
concepts  associated  with  microprocessor- based  computer  systems  selling 
for  less  than  $20,000.  As  long  as  we  recognize  that  these  are  basically 
desktop  computer  systems,  this  is  not  teixibly  important  in  the  discussion 
of  architecture  except  to  point  out  the  following: 

•  As  personal  computers  have  progressed  in  price/performance,  it  has 
become  obvious  that  users  should  be  concerned  about  what  is  on  the 
other  side  of  the  screen.  Even  casual  users  of  systems  have  suddenly 
become  painfully  aware  of  the  640K  barrier  built  into  their  hot  micro- 
processor-based systems,  and  when  IBM  announced  its  micro-channel 
architecture  along  with  the  PS/2,  there  were  arguments  about  whether  it 
was  useful,  desirable  or  necessary  to  implement  advanced  applications. 

•  It  is  difficult  not  to  be  concerned  about  architecture  when  you  find  you 
must  be  concerned  with  concepts  of  expanded  memory,  extended 
memory,  disk  caching,  shadow  memory,  RAM  disks  and  memory 
management  utility  programs  that  require  a  systems  programmer  to 
understand  them — all  to  take  advantage  of  the  additional  RAM  you  need 
on  your  system. 

•  GUIs  may  hide  architectural  limitations  of  systems,  but  they  don't  help 
very  much  when  an  application  requires  more  conventional  memory 
than  the  system  can  find  for  it,  or  when  all  the  windows  shut  down  with 
an  unrecoverable  system  error. 

IS  management  rated  IWSs  highest  as  being  cost  effective,  easy  to  pro- 
gram, easy  to  operate,  easy  to  use,  the  best  "bargain,"  and  having  the  best 
open  architecture.  However,  there  doesn't  seem  to  be  any  question  that 
users  are  currentiy  concerned  with  a  great  deal  of  complexity  in  making 
effective  use  of  all  the  wonderful  technology  that  is  becoming  available  on 
the  desktop. 
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All  of  this  brings  us  to  the  subject  of  operating  systems — but  first,  let's  dig 
one  level  deeper  into  the  hardware. 

5c  Other  Microprocessors 

IS  management  was  not  asked  to  rate  this  processor  category,  but  it  has 
been  included  as  a  logical  extension  of  downsizing. 

Microprocessor  technology  is  advancing  so  rapidly  that  even  general- 
purpose  microprocessor-based  systems  are  threatened  with  "downsizing" 
of  certain  functions  into  application- specific  integrated  circuits  (ASIC) 
and  other  embedded  processors.  Intelligent  peripherals  (printers,  DASD, 
scanners,  optical  memory,  audio  recognition  systems,  image  processing, 
etc.)  are  already  appearing;  and  even  complex  applications  (such  as  expert 
systems)  will  be  differentiated  and  mechanized  in  silicon. 

The  very  IWSs  being  used  for  CAD/CAM  will  permit  the  cost-effective 
design  of  these  ASICs,  and  one  of  their  primary  benefits  will  be  that  they 
will  not  require  the  complex  systems  software  and  expensive  applications 
software  currently  evolving  for  RISC  and  IWSs. 

B  

Operating  Systems 

Operating  systems  are  designed  to  make  computer  hardware  easier  to  use. 
A  brief  history  follows: 

•  It  was  discovered  early  on  that  getting  data  and  programs  together  in 
memory  presented  a  substantially  more  difficult  programming  problem 
than  did  the  actual  logic  and  arithmetic  operations  performed  on  the 
data.  Therefore,  input/output  control  systems  (lOCSs)  were  developed. 

•  Then,  when  there  were  the  scheduling  problems  associated  with  getting 
jobs  through  the  system,  simple  stack  job  monitors  were  developed. 

•  Since  CPUs  were  so  fast  (even  25  years  ago),  commercial  data  process- 
ing applications  were  "I/O-bound."  So,  in  order  to  keep  the  processor 

busy,  multiprogramming  was  invented.  This  added  another  level  of 
complexity  in  terms  of: 

-  Job  and  priority  scheduUng 

-  Accounting  and  billing  for  systems  use 

-  Access  to  shared  resources 

-  Storage  management  (memory  tended  to  become  fragmented) 
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•  Concurrent  with  multiprogramming  on  the  commercial  data  processing 
side,  timesharing  developed  for  scientific  and  engineering  applica- 
tions; and,  because  of  the  slow  speed  of  keyboard  interaction,  every  user 
could  be  made  to  feel  that  he/she  had  exclusive  use  of  the  processing 
resource. 

•  Because  of  fragmentation  of  the  limited  memory  then  available  (1  or  2 
meg),  and  the  requirements  of  multiple  users  and  larger  programs  (espe- 
cially the  large  matrices  needed  by  some  scientific  and  engineering 
problems),  memory  management  became  a  primary  concern;  this  re- 
sulted in  the  development  of  virtual  storage  systems. 

•  Virtual  storage  systems  solved  for  all  time  the  trouble  of  having  to  worry 
about  keeping  CPUs  busy.  At  first,  these  systems  were  able  to  keep  the 
CPU  busy  without  doing  any  useful  work — even  the  largest  systems 
spent  all  of  their  time  "thrashing"  away  at  managing  memory  and  were 

unable  to  get  any  useful  work  done.  This  problem  was  solved  with  a 
combination  of  improved  systems  software,  faster  CPUs  and  more  real 
memory,  but  the  fact  remains  that  large  mainframes  (the  target  of 
downsizing)  spend  most  of  their  time  in  "managerial"  overhead. 

•  Due  to  the  fact  that  IBM  had  several  operating  systems  to  support,  it  was 
found  desirable  to  be  able  to  run  "virtual  machines"  on  the  same  system 
so  systems  programmers  could  debug  the  various  operating  systems 
being  developed.  This  resulted  in  VM,  which  permits  various  users  to 
have  their  own  operating  environments  (or  virtual  machines)  on  the 
same  system.  VM  is  important  conceptually  because  "shells"  to  run 
both  UNIX  and  proprietary  operating  systems  are  becoming  quite 
important  at  all  levels  in  the  processing  hierarchy. 

•  Along  the  way,  large  mainframes  have  had  their  own  addressing  prob- 
lems, which  have  been  solved  by  MVS/XA  and  MVS/ESA,  etc.  These 
Extended  Architecture  systems  have  been  referred  to  by  some  familiar 
with  the  history  of  IBM  mainframe  architecture  as  "extended  accommo- 
dation," the  impHcation  being  that  there  remain  fundamental  architec- 
tural flaws  in  the  mainframe  hardware. 

•  Then,  of  course,  shared  resources  and  the  very  complexity  of  mainframe 
operating  environments  raise  immediate  problems  of  data  security  and 
privacy  protection — issues  that  still  have  not  been  adequately  resolved  in 
many  systems.  And,  it  should  be  pointed  out,  neither  privacy  nor  data 
integrity  can  be  assured  in  a  system  that  is  not  secure. 

We  have  gone  through  this  brief  history  of  operating  systems  development 
because  the  RISC  systems  and  FWSs  used  as  file  and  data  base  servers  in 
downsized  environments  will  be  confronted  with  all  of  the  problems 
briefly  outlined  above,  and  their  operating  systems  were  not  designed  with 
such  complex  environments  in  mind.  Operating  systems  are  currently  a 
hot  topic  for  good  reason — they  will  determine  the  success  or  failure  of 
many  downsizing  efforts. 
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Exhibit  ni-2  presents  the  primary  operating  systems  abstractions  [2]  that 
have  developed  over  the  years  and  some  of  the  attributes  associated  with 
those  abstractions.  These  abstractions  will  be  used  to  provide  an  operating 
system  "report  card"  later  in  the  report. 


EXHIBIT  III-2 


Operating  System  Abstractions  and  Attributes 


Abstractions 

Attributes 

Process 

Concurrency 

Timing 
"Deadlock" 

Memory  Management 

Fragmentation 
Virtual/real  storage 
Process  isolation 
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Data  Protection  &  Storage 

Object  access  control 
Data  flow  control 
Information  flow  control 

Scheduling  &  Resource 
Management 

Time-scale  decomposition 

Timsharing 

Timeslicing 

Queue  management 

Performance  prediction 

Systems  Structure 

Integration  of  above 
Resource  level  management 
Virtual  machines 
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Abstraction  &  Technology 

Interplay 

-  Software 

-  Firmware 

-  Hardware 
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c  

Applications  and  Tools 

Terminology  has  always  been  a  problem  in  the  computer  industry  from  the 
day  someone  called  an  early  computer  a  "giant  electronic  brain."  How- 
ever, we  find  the  currently  popular  misuse  and  appropriation  of  the  term 
"application"  especially  perplexing.  There  was  little  confusion  about  the 
term  application  before  the  personal  computer  hype  started  in  the  1980s. 
■  Practically  anyone  associated  with  the  computer  industry  would  have 
agreed  with  the  definition  contained  in  The  Dictionary  of  Computing; 
Oxford  Science  Publications,  1983.  That  definition  is  the  one  we  will  use 
in  this  report,  and  it  is  as  follows: 

Applications  Program  -  "Any  program  that  is  specific  to  the  par- 
ticular role  that  a  given  computer  performs  within  a  given  organi- 
zation and  makes  a  direct  contribution  to  performing  that  role.  For 
example,  where  a  computer  handles  a  company's  finances  a  pay- 
roll program  would  be  an  applications  program.  By  contrast,  an 
operating  system  or  a  software  tool  may  both  be  essential  to  the 
effective  use  of  the  computer  system,  but  neither  makes  a  direct 
contribution  to  meeting  the  end-user's  eventual  needs." 

The  problems  started  when  everyone  started  talking  about  users  being 
interested  only  in  "solutions"  and  not  problems.  At  that  point,  personal 
computer  vendors  started  looking  around  for  application  "solutions"  and 
all  they  found  were  some  word  processing,  spreadsheet  and  data  base 
packages.  These  were  then  sold  as  "solutions"  and  labeled  as  applications. 
It  seems  patently  clear  that  none  of  these  packages  is  an  applications 
program  by  the  above  definition.  They  are  tools,  just  like  a  typewriter,  an 
adding  machine,  and  a  cash  register  are  tools.  More  specifically,  they  are 
applications  enabling  tools,  just  like  a  programming  language. 

Perhaps  a  brief  description  of  a  simple  applications  system  s  architecture 
will  help  to  explain  why  these  tools  do  not  qualify  as  applications,  and 
also  provide  a  framework  for  discussing  how  and  what  may  be  downsized 
from  mainfi-ames. 

1.  Computer  Applications  Systems  Architecture 

An  applications  system  or  program  has  five  essential  elements: 

•  It  must  have  an  identified  and  specified  source  of  input  data. 

•  It  must  have  a  set  of  logic  and  procedures  which  process  those  data  in 
the  memory  of  the  computer. 
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•  It  must  be  able  to  communicate  (move)  the  input  data  (or  information)  to 

the  computer  memory  and  the  output  data  (or  information)  out  of  the 
computer  memory. 

•  It  must  have  some  medium  (external  to  memory)  on  which  to  store  data 
(and  programs)  before  and  after  processes  (for  future  use  in  other  pro- 
cesses). 

•  It  must  have  some  medium  on  which  to  produce  output  of  the  process. 

All  of  the  above  elements  of  an  applications  system  must  be  integrated  in 
order  to  make  a  "specific  contribution  to  the  role  of  the  organization." 

It  seems  obvious  that  when  I  bring  up  my  spreadsheet  package  and  it 
presents  me  with  a  blank  screen,  I  have  just  begun  to  develop  an  applica- 
tion. Spreadsheet  packages  can  be  used  to  develop  entire  applications, 
and  for  data  storage  between  runs  or  processes.  However,  their  suitability 
for  replacing  downsized  production  applications  is  highly  problematic. 

2.  Examples  of  Functions  and  Media 

Exhibit  ni-3  shows  some  of  the  functional  and  media  combinations 
associated  with  computer  applicauons  systems.  We  shall  refer  back  to  this 
later,  but  at  the  present  time  is  important  to  make  several  points. 

•  Computer  applications  are  only  part  of  business  systems.  Even  where 
the  computer/employee  ratio  is  high,  business  systems  remain  highly 
dependent  upon  paper. 

•  Office  automation  systems  have  automated  the  production  of  paper 

documents,  and  all  of  these  documents  require  human  handling  and 
"processing"  (reading,  routing  and  'rithmetic).  All  too  frequently  data 

from  computer-produced  reports  are  re-entered  in  other  applications. 

•  One  of  the  most  promising  opportunities  of  downsizing  is  to  "squeeze" 
the  paper  out  of  computer  applications  by  re-engineering  existing  appli- 
cations during  the  downsizing  process. 

•  A  comparable  opportunity  exists  to  eliminate  the  transfer  of  data  be- 
tween applications  by  physically  moving  magnetic  media  between 
applications  systems  (floppy  disks,  tapes,  etc.). 

Downsizing,  coupled  with  the  reduction  in  paper  flow  and  the  physical 
transfer  of  magnetic  media  between  (and  among)  applications  systems, 
implies  that  distributed  data  bases  will  play  an  increasingly  important  role 
as  downsizing  progresses. 


UIDSA 


©  1992  by  INPUT.  Reproduction  Prohibited. 


ni-13 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


EXHIBIT  III-3 


Application  Systems  Architecture,  Functions  and  IVIedia 
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Computer — >  Computer 
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Human  < — >  Computer 

Optical  Storage 
Microfilm  (fiche) 

Computer  — >  Device 

D  

Data  Base  Management 

Despite  the  trend  to  downsizing,  only  6%  of  IS  management  felt  that 
mainframes  would  actually  be  replaced.  The  future  role  of  mainframes 
seems  assured  as  "superservers."  However,  50%  of  IS  management 
respondents  felt  that  downsizing  would  result  in  a  transfer  of  responsibility 
for  "data  and/or  management  information  quality,"  and  that  many  users 
and  vendors  do  not  understand  this.  Since  only  22%  of  vendors  agreed 
that  such  a  transfer  of  responsibility  would  take  place,  it  is  probable  that 
users  buying  vendor  downsizing  "solutions"  are  in  for  something  of  a 
surprise. 

Because  data  base  management  is  the  key  to  successful  downsizing,  it  is 
necessary  to  take  a  look  at  data  models,  which  are,  in  effect,  the  data 
architectures  of  commercial  applications.  About  ten  years  ago,  during  an 
INPUT  research  effort  on  data  models,  one  IS  executive  said:  "I  don't 
want  to  talk  about  data  models;  in  fact,  I  don't  even  like  to  think  about 
data  models — the  whole  subject  bores  me."  But,  please  bear  with  us — this 
is  important. 

1.  Files,  Matrices  and  Data  Models 

Exhibit  ni-4  depicts  various  data  models.  Each  has  a  significant  message. 
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EXHIBIT  III-4 


Files,  Matrices  and  Data  IVIodels 
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a.  Sequential  Files 

Data  base  management  has  always  been  a  problem.  Early  programmers 
and  users  had  to  deal  with  card  decks  on  which  their  programs  and  data 
were  stored.  It  wasn't  fun.  The  "graphics  user  interface"  was  frequendy 
the  view  of  a  bunch  of  holes  in  an  uninterpreted  punch  card.  Those  were 
not  the  good  old  days. 

Magnetic  tape,  which  replaced  punch  cards  as  the  primary  input  source  to 
commercial  applications,  was  also  a  serial  medium.  Sequencing  (sorting) 
of  both  master  files  and  changes  (transactions)  was  necessary  in  order  to 
update  files  with  one  pass  of  the  master  tape.  It  was  also  found  that  data 
had  to  be  exchanged  between  various  organizational  entities  in  order  to 
build  new  applications  programs.  These  imported  files  were  frequendy  in 
a  different  sequence  and  this  again  required  sorting  and  the  building  of 
another  master  file  to  support  a  specific  application. 

Obviously,  sorting  was  an  exceptionally  important  function  in  commercial 
applications  in  the  days  of  serial  batch  data  processing.  The  fact  that  it 
remains  such  an  important  function  on  mainframe  superservers  in  today's 
environment  (as  mendoned  previously)  is  somewhat  difficult  to  under- 
stand, but  it  supports  the  fact  that  most  users  prefer  to  view  and  work  with 
their  data  in  some  logical  sequence.  In  addition,  sequenced  data  are 
substantially  easier  and  faster  to  retrieve  (even  if  the  sequencing  is  in 
indices  rather  than  the  physical  data).  It  is  unlikely  that  sorting  on 
superservers  is  going  to  diminish  as  files  are  transferred  and  data  are 
distributed  to  downsized  platforms.  In  fact,  it  is  more  likely  that  increased 
demands  for  file  transfers  for  downsized  applications  will  increase  serial 
batch  processing  against  existing  data  bases.  This  is  an  important  consid- 
eration in  the  overall  economics  of  downsizing. 

The  problem  with  serial  batch  processing  was  primarily  associated  with 
building  and  maintaining  separate  master  files  for  various  applications. 
That  is  how  data  base  management  systems  came  into  being. 

b.  Data  Models 

Nearly  thirty  years  ago,  in  response  to  the  problems  of  building  and 
maintaining  master  files  that  had  interapplication  dependencies,  the  Gen- 
eral Electric  Company  came  up  with  something  called  Integrated  Data 
Store  (IDS).  It  was  a  data  base  management  system  built  on  the  network 
data  model.  IBM  originally  rejected  even  the  concept  of  EDS,  stating  that 
it  wasn't  needed  because  ISAM  would  solve  all  of  the  world's  problems. 

However,  GE  was  a  big  IBM  customer  and,  working  through  GUIDE  and 
CODASYL,  GE  representatives  managed  to  get  IBM  customers  interested 
in  data  base  management  systems,  and  even  got  the  network  model  ac- 
cepted as  a  data  base  "standard"  by  CODASYL  (Exhibit  in-4b). 
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IBM  didn't  go  along  with  the  data  base  standards  effort  because  it  was 
working  on  its  own  data  base  management  strategy.  This  strategy  culmi- 
nated in  IMS,  which  was  built  on  the  hierarchical  data  model  (Exhibit  ni- 
4c).  IMS,  and  the  hierarchical  model,  became  the  de  facto  standard  for 
large  IBM  mainframe  data  bases  despite  the  availability  of  attractive 
alternatives  from  competitive  vendors.  Early  in  the  life  of  IMS,  a  respon- 
dent to  an  INPUT  study  stated:  "IMS  has  managed  to  bum  more  CPU 
cycles  than  IBM  ever  imagined  in  its  fondest  dreams."  After  years  of 
improvement,  IMS  performance  is  now  used  as  a  benchmark  for  transac- 
tion processing.  Many  downsized  applications  will  remain,  either  directly 
or  indirectly,  dependent  upon  IMS  for  data. 

One  of  IMS's  major  weaknesses  is  the  reason  it  will  be  around  for  a  long 
time:  it  lacks  flexibility.  Once  established,  the  structure  of  a  hierarchical 
data  base  is  difficult  to  reorganize;  and,  more  importantly,  so  is  the  busi- 
ness organization  the  data  base  supports.  For  this  reason,  IBM  found  it 
extremely  difficult,  if  not  impossible,  to  use  IMS  for  many  of  its  major 
internal  information  systems.  In  fact,  based  on  the  experience  of  large 
IBM  customers,  IBM  has  warned  that  selecting  a  DBMS  is  a  "thirty-year 
decision".  [1]  Since  IMS  didn't  become  prominent  until  the  1970s,  we 
can  expect  it  to  be  around  well  beyond  the  turn  of  the  millennium. 

While  IMS  was  being  installed  in  customer  accounts,  the  relational  model 
was  being  invented  by  Dr.  E.F.  Codd  of  the  IBM  San  Jose  Research 
Laboratory  in  the  late  1960s  (Exhibit  ni-4d).  It  had  a  long  gestation 
period  (over  10  years)  before  being  announced  by  IBM  as  DB2.  The 
relational  model  represents  data  in  tables  of  unsequenced  (unsorted) 
relationships.  Despite  the  fact  that  it  is  a  mathematically  sound  model  (as 
described  by  Dr.  Codd),  the  relational  model  is  easy  to  visualize — it  is 
similar  to  decks  of  unsorted  punch  cards. 

The  relational  algebra  (select,  project,  cartesian-product,  union  and  set- 
difference)  is  performed  on  the  relational  tables  (sets)  just  as  the  old  tab 
supervisor  "wired  boards"  and  ran  his  various  decks  through  collators, 
sorters  and  tabulators — except  no  sorting  is  permitted  in  the  relational 
model.  Since  the  algebra  processes  sets,  some  derived  operations  of  the 
algebra  (such  as  an  unrestricted  JOIN)  can  present  substantial  performance 
problems.  Even  IBM  acknowledged  these  performance  problems;  that  is 
the  reason  that  a  relational  DBMS  was  not  announced  for  IBM  main- 
frames for  over  10  years.  Today,  performance  optimization  of  relational 
systems  remains  a  major  technical  challenge,  and  the  quality  of  relational 
products  varies  accordingly.  Various  relational  products  also  vary  consid- 
erably in  conforming  to  Dr.  Codd's  specifications — there  are  more  "rela- 
tional-Hke"  systems  than  there  are  pure  relational  systems. 

The  relational  model  is  important  for  many  reasons: 


UIDSA 


©  1992  by  INPUT.  Reproduction  Prohibited. 


ni-17 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


•  It  is  the  preferred  model  for  distributed  data  base  servers  and  open 
systems. 

•  It  is  also  the  supponed  data  model  for  IBM's  SAA — providing  reason- 
able certainty  of  becoming  an  industry  standard. 

•  The  preferred  reladonal  language — SQL  (Structured  Query  Language  or 
Sequel) — has  become  the  de  facto  standard  for  data  base  distribution,  the 
glue  for  integrating  the  emerging  downsized  environment. 

Although  there  are  other  promising  data  models,  such  as  the  Entity- 
Relationship  model,  they  have  not  currendy  achieved  significant  market 
penetration.  Neither  IS  management  nor  data  base  administrators  seem 
ready  for  more  complexity  in  the  area  of  data  models.  However,  the 
predominance  of  spreadsheet  "data  bases"  at  the  IWS  level  may  result  in 
unprecedented  complicadons  for  the  data  base  administrator. 

Overall,  INPUT  believes  that  reladonal  data  base  technology  will  play  a 
major  role  in  the  downsizing  revolution.  Users  understand  it  and  it  will 
simplify  the  IWS-to-server  connecdon.  Its  adopdon  will  be  a  key  factor  in 
the  pace  of  the  downsizing  revolunon. 

c.  Matrices,  Spreadsheets  and  Data  Bases 

Personal  computer  users  have  not  taken  to  DBMSs  with  enthusiasm 
because  construcdng  an  application  usmg  even  the  relatively  simple  PC 
DBMSs  in  common  use  means  that  one  must  begin  to  understand  some  of 
the  basic  principles  of  systems  design.  This  has  not  come  easily  to  casual 
users,  and  has  resulted  in  the  more  popular  spreadsheet  packages  being 
used  to  construct  applications  and,  more  importantly,  to  serve  as  data  base 
systems. 

The  ability  to  view  a  pordon  (or  all)  of  a  two-dimensional  matrix  as  a  table 
for  purposes  of  sorting  and  query  has  led  personal  computer  users  to 
construct  real  computer  applications  using  their  misnamed  spreadsheet 
"applications."  This  means  that  data  are  stored,  updated  and  retrieved  all 
within  the  spreadsheet  program.  Because  spreadsheet  programs  are 
somewhat  like  the  von  Neumann  architecture  run  amok,  with  data  and 
operations  indistinguishable  and  splattered  throughout  the  work  space,  it 
violates  all  principles  of  data  and  program  isolation  and  has  potentially 
(frequently  realized)  disastrous  consequences  for  data  integrity. 

Since  much  of  the  impetus  for  downsizing  is  based  on  access  to  corporate 
data  bases  so  the  user  does  not  have  to  take  a  report  produced  by  the  IS 
department  and  key  information  into  a  spreadsheet  matrix,  it  seems  inevi- 
table that  many  of  these  data  (which  are  necessary  for  downsized  applica- 
tions) will  either  trickle  (or  gush)  down  to  the  desktop  regardless  of  how 
many  servers  they  pass  through.  To  the  degree  that  these  data  are  stored 
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in  spreadsheet  programs,  they  will  be  virtually  unmanageable.  As  spread- 
sheets gain  functionality  the  problem  only  gets  worse;  think  of  the  prob- 
lems of  multidimensional  matrices. 

2.  The  Importance  of  Data  Base  Management  in  Downsizing 

The  importance  of  DBMSs  in  a  central  data  base  environment  is  depicted 
in  Exhibit  III-5.  The  same  classes  of  users  in  this  general  systems  archi- 
tecture will  exist  in  the  downsized  environment,  regardless  of  the  formal 
titles. 

•  Naive  users  will  vary  from  data  entry  personnel  to  corporate  executives, 
but  they  will  use  the  application  system  for  a  specific  purpose  and  will 
not  have  to  be  concerned  about  either  the  physical  or  logical  data  struc- 
tures underlying  the  specific  application  nor  will  they  manipulate  or 
quiery  the  data  base  (although  they  may  be  familiar  with  several  applica- 
tions). 

•  Applications  programmers  will  exist  to  define  the  applications  for  both 
naive  and  casual  users — whether  by  designing  a  screen,  laying  out  a 
spreadsheet  program  or  developing  a  mission-critical  application.  The 
qualifications  of  these  "applications  programmers"  will  vary  over  an 

extreme  range  also.  Applications  may  be  developed  by  entry-level 
personnel  because  they  "know  the  package"  and  help  others  in  their 
work,  or  they  may  be  corporate  executives  who  prefer  to  write  their  own 
programs  because  it  is  "fun."  Application  development  in  a  downsized 
environment  will  have  a  tendency  to  be  unstructured. 

•  Casual  users  who  are  able  to  make  queries  of  application  data  bases  can 
use  PC  tools  to  build  personal  data  bases,  which  may  then  be  used  as  a 
source  of  power.  However,  such  personal  data  bases  can  create  horren- 
dous data  management  problems. 

•  Data  base  administrators  will  exist  in  the  downsized  environment 
regardless  of  what  they  are  called.  It  will  be  found  that  leaving  data  base 
administration  to  individual  users  will  lead  to  chaos,  and  the  central  data 
base  administrators  are  saying  responsibility  for  data  quality  is  going  to 
be  transferred  whether  users  know  this  or  not.  The  need  to  coordinate 
file  transfers  and  maintain  data  dictionaries  and  documentation  will  have 
to  fall  on  someone  at  the  local  level.  This  can  become  an  important 
element  when  cost  justifying  downsizing. 

Considerations  of  data  base  quality  and  the  architecture  for  data  base  use 
will  be  critical  factors  in  the  success  or  failure  of  downsizing  to  achieve  its 
objectives.  Imposing  such  discipline  on  free-wheeling  end  users  who  have 
finally  shattered  the  walls  of  the  traditional  "glass  house"  will  not  be  easy. 
The  end-user  revolution  has  been  a  long  and  bitter  struggle  in  many 
organizations,  and  systems  discipline  is  not  going  to  be  easy  to  enforce. 
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This  brings  us  to  the  point  where  we  will  stop  looking  behind  the  screen 
and  start  looking  beyond  the  screen. 


EXHIBIT  III-5 
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E  

Business  Processes 

As  soon  as  we  stop  staring  at  the  screen  and  look  around,  we  will  notice 
that  despite  all  of  the  computer  equipment  that  has  been  installed  in 
offices,  there  is  still  paper  everywhere.  Modem  civilization  and  com- 
merce have  been  built  on  paper,  and  paper  remains  the  primary  medium 
for  most  business  processes  and  communications. 

1.  Computers,  Paper  and  People 

The  impact  of  getting  computer  power  to  the  people  has  resulted  in  auto- 
mating the  production  of  paper  and  making  it  prettier,  but  the  core  paper 
processes  remain  firmly  in  place  in  most  organizations.  It  is  INPUT'S 
opinion  that  this  is  true  for  two  reasons: 

1.  Most  substantive  business  applications  (and  their  supporting  data 
bases)  have  remained  on  mainframe  computers,  under  the  control  of  the  IS 
department  and  the  corporate  controller.  Central  planning  and  control 
functions  thrive  on  paper,  and  most  financial  people  feel  extremely  inse- 
cure without  it. 

2.  Mainframe  "solutions"  to  office  systems  problems — specifically  the 
reduction  (or  control)  of  paper  flow — have  been  too  expensive  to  be  easily 
cost  justified. 

The  extension  of  personal  computer  power  to  the  desktop  while  data 
remained  on  central  computer  systems  merely  made  another  source  of  data 
and  information  available  for  the  knowledge  worker,  who  was  already 
surrounded  by  "multimedia"  sources  (Exhibit  III-6).  In  addition  to  main- 
frame data  bases,  the  user  was  already  exposed  to  the  following: 

•  The  regular  flow  of  paper  documents  into,  and  through,  the  organization 

•  Paper  files 

•  Libraries  of  professional  publications  and  reference  works 

•  Microfiche  and  microfilm  archival  records 

•  Face-to-face  and  telephone  conversations  with  other  humans  (most  of 
which  result  in  paper  documentation  and  confirmation) 
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EXHIBIT  III-6 


Business  Processes  and  Media  Conversion 
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And,  since  the  personal  computer  arrived  in  the  1980s: 

-  Personal  data  bases  developed  and  maintained  by  the  individual 

-  Direct  data  interchange  through  floppy  disks 


-  Electronic  mail  and  messaging 

-  And,  FAX — far  from  a  new  development — has  suddenly  become  all 
the  rage,  and  dumps  paper  from  point  to  point  fasten 

The  primary  benefit  of  downsizing  existing  applications  (and  their  sup- 
porting data)  to  office  work  units  will  be  the  recognition  of  the  need  to 
integrate  all  of  these  diverse  data  and  information  sources.  It  is  one  thing 
to  exchange  voluminous  amounts  of  data  and  paper  with  a  remote  main- 
frame computer  installation  and  quite  another  to  know  first-hand  how 
burdensome  and/or  useful  this  information  is  in  the  actual  working  envi- 
ronment. 
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Even  if  downsized  applications  are  not  re-engineered  (and  they  usually 
should  be)  moving  these  applications  and  their  supporting  data  directly 
into  the  working  environment  will  prompt  rapid  innovation  in  the  basic 
business  systems  themselves.  The  benefits  from  substituting  electronic  for 
paper  media  in  the  office  will  far  outweigh  any  savings  from  cutting  back 
on  mainframe  expense;  and  early  (and  continuing)  end-user  involvement 
in  the  development  (and  maintenance)  processes  should  improve  both 
white-collar  productivity  and  the  effective  application  of  information 
technology  to  business  systems. 

The  architectures  of  both  computer  systems  and  business  processes  are 
bound  to  change  when  a  single  5.25-inch  optical  disk  (CD  ROM  at 
present)  can  hold  not  only  the  entire  corporate  planning  data  base,  but  also 
all  of  the  paper  files  in  the  average  office. 

With  all  this  potential  lying  just  beyond  the  screen,  what  is  standing  in  the 
way  of  immediate,  massive  downsizing? 

Essentially,  it  is  the  well-founded  IS  fear  that  downsizing  may  result  in  a 
complex  "network  of  systems"  that  is  unmanageable. 

F  

Networks  of  Systems 

Exhibit  III-7  depicts  a  fairly  simple  architectural  representation  of  a 
"network  of  systems"  that  could  develop  among  corporate  planning, 
accounting,  shipping,  and  the  outside  world.  All  of  these  functions  are 
interrelated  and  must  be  kept  in  synchronization;  otherwise  unfortunate 
consequences  can  result.  For  example: 
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EXHIBIT  III-7 
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A  number  of  years  ago,  corporate  planners  for  a  major  computer  manufac- 
turer (that  shall  remain  unnamed)  were  reviewing  the  data  dictionary  for 
the  corporate  planning  data  base.  This  data  base  tracked  the  movement  of 
each  box  from  the  time  it  was  placed  on  order  until  it  was  scrapped. 
Among  the  data  elements  were  date  of  order,  scheduled  for  production, 
scheduled  for  completion,  shipped  but  unbilled,  etc.  All  of  these  were 
quite  understandable,  but  then  someone  spotted  the  category  "billed  but 
unshipped"! 


The  designer  of  the  data  base  was  promptly  called  on  the  carpet  to  explain 
this  obvious  error.  Asked  why  the  category  was  included,  he  stated 
simply:  "Because  it  happens  all  the  time.  We  bill  for  things  that  haven't 
been  shipped  fairly  frequently,  and  sometimes  we  even  get  paid."  It  was 
also  found  that  salesmen  were  spending  a  considerable  amount  of  time 
working  with  customers  on  billing  problems,  and  some  customers  were 
delaying  payment  until  they  received  a  proper  bill.  The  company  had  a 
classic  problem  with  data  base  synchronization  and  integrity  between 
shipping,  accounting,  and  field  engineering. 


III-24 


©  1992  by  INPUT.  Reproduction  Prohibited. 


UIDSA 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


What  IS  management  fears  is  that  downsizing  (and  distributed  data  bases) 
will  result  in  exactly  the  same  problems  encountered  by  decentralized  data 
processing  and  standalone  applications  systems.  These  data  and  informa- 
tion quaUty  problems  are  depicted  in  Exhibit  111-8.  INPUT  believes  there 
are  very  real  problems  associated  with  distributed  data  base  management, 
but  technology  has  improved  substantially  in  the  last  few  years.  It  is 
possible  that  some  IS  managers  are  more  concerned  about  data  quality 
problems  than  the  situation  warrants. 


EXHIBIT  III-8 
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Under  any  circumstances,  data  quality  and  security  are  central  issues  in  the 
downsizing  environment  of  the  1990s  and  they  warrant  additional  re- 
search. A  report  on  Data  Quality  and  Security  in  Downsized  Environ- 
ments will  be  included  in  this  report  series. 
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Competing  Architectural  Concepts 


Although  the  fundamental  technical  issues  associated  with  downsizing  are 
data  quality  and  security,  there  are  a  number  of  peripheral  issues  that 
surface  as  competing  architectural  concepts. 

A  

Open  versus  Proprietary  Systems 

The  open  versus  proprietary  systems  controversy  surfaces  at  several 
levels — hardware  and  systems  software  behind  the  screen,  at  the  screen 
itself  in  terms  of  GUIs,  and  beyond  the  screen  in  standards  activities.  We 
will  not  concern  ourselves  here  about  arguments  as  to  whether  Sun's 
UNIX-SPARC  system  is  more  (or  less)  open  than  MS-DOS  for  Intel 
processors.  The  open  versus  proprietary  issue  for  downsizing  is  clearly 
between  IBM's  SAA  and  UNIX.  In  fact,  it  is  INPUT'S  opinion  that  the 
real  downsizing  competition  will  be  between  UNIX-based  servers  and  the 
AS/400 — a  battle  that  really  hasn't  yet  been  joined  (except  within  IBM). 

1.  The  SAA  World 

Regardless  of  what  one  thinks  about  the  progress  of  SAA,  it  is  obvious 
that  it  specifically  concerns  itself  with  "networks  of  systems"  and  in 
shielding  the  user  (or  applications  developer)  from  the  complexities 
behind  the  screen.  The  major  SAA  abstractions  are: 

•  A  Common  User  Access  (CUA)  to  all  SAA  systems 

•  A  Common  Programming  Interface  (CPI)  and  compatible  applications 
enabling  tools  (including  the  relational  model  and  SQL) 

•  Portability  of  applications  across  the  hierarchy  of  SAA  operating  envi- 
ronments 

•  A  cooperative  processing  environment  featuring  client  ("requester") 
architecture 
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•  A  commitment  to  provide  network  management  facilities  for  increas- 
ingly complex  networks  of  systems 

•  And,  last  but  not  least,  a  comprehensive  plan  to  develop  an  industrial- 
strength  distributed  data  base  management  system 

IBM's  vision  of  the  1990s  was  clearly  presented  at  conferences  for  the 
computer  services  and  consulting  industry  and  to  IBM  user  organizations 
even  before  SAA  was  announced.  The  fact  that  SAA  is  an  effort  to  get  the 
IBM  house  in  order,  and  is  self-serving  in  the  sense  that  acceptance  of 
SAA  effectively  locks  out  many  competitive  hardware/software  vendors, 
is  beside  the  point — SAA  does  address,  head  on,  the  most  serious  architec- 
tural problems  in  the  commericial  data  processing  market. 

In  addition,  the  need  for  co-existence  with  the  outside  world  was  recog- 
nized at  the  time  of  the  SAA  announcement,  and  an  integral  part  of  SAA 
was  the  Common  Communications  Support  (CCS),  which  was  stated  as 
being  an  extension  of  SNA  (the  de  facto  standard  in  the  commmerical 
market)  and  ''selected"  international  standards.  Once  again,  though  IBM's 
standards  activities  may  appear  to  be  self-serving  in  proposing  APPC  with 
LU.6.2  and  PU  2A  as  standards  (as  well  as  APPN),  IBM  certainly  isn't 
doing  any  more  than  other  vendors  in  attempting  to  protect  its  (and  its 
customers)  interests.  In  addition,  IBM  has  been  the  recipient  of  some 
rather  opprobrious  treatment  at  the  hands  of  standards  organizations  going 
back  to  early  COBOL  and  ASCII  decisions. 

2.  The  RISC/UNIX  World 

Exhibit  rV-l  presents  a  slightly  modified  diagram  of  the  SAA  and  outside 
worlds  which  was  published  by  IBM  around  the  time  of  SAA  announce- 
ment. Since  IBM  had  already  supported  UNIX  in  the  form  of  AIX  prior  to 
the  announcement  of  SAA,  it  can  be  assumed  that  UNIX  and  SQL  were 
the  preferred  "standards"  for  asynch  connection  with  the  outside  world  of 
other  proprietary  and  "open"  systems. 
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EXHIBIT  iV-1 
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It  was  after  the  announcement  of  SAA  that  AT&T  and  Sun  Microsystems 
tried  to  gain  control  (or  bring  order  to)  the  UNIX  world  by  preaching 
"open  systems"  and  rallying  around  the  SPARC  processor.  This  brought 
on  the  revolt  by  HP,  DEC,  IBM  and  others  which  led  to  the  founding  of 
the  Open  Software  Foundation  (OSF).  The  success  of  RISC-based  work- 
stations and  the  apparent  attraction  of  the  "open  systems"  movement  re- 
opened longstanding  hardware/software  conflicts  within  IBM.  For 
example: 

•  The  previously  described  RISC,  CISC,  HLL  controversy 

•  The  old  DOS...VSE  versus  OS...MVS/ESA  war  of  simplicity  versus 
complexity.  The  latest  battle  was  fueled  by  young  IBM  computer 
scientists  who  had  cut  their  teeth  on  UNIX  systems  during  their  aca- 
demic days. 
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•  The  internal  antipathy  of  IBM's  large  mainframe  crowd  against  mini- 
computers (except  the  9370) — including  the  AS/400,  which  was  doubly 
damned  because  it  was  also  considered  an  architectural  threat  to  the  370 
architecture  machines 

•  The  general  reluctance  on  the  part  of  practically  all  of  the  internal  IBM 
development  groups  to  submit  to  the  discipline  imposed  by  SAA 

The  result  was  that  IBM  created  a  RISC/UNIX  world  around  the  RS/6000 
that  is  a  parallel  strategy  to  SAA.  Considering  the  architectural  position- 
ing of  the  RS/6000  and  the  AS/400  in  the  downsizing  world,  it  is  obvious 
that  IBM  has  recreated  conceptual  problems  and  confusion  at  the  mini- 
computer (server)  level  for  its  customers. 

However,  it  is  both  possible  and  probable  that  IBM  either  knows  (or  feels) 
that  UNIX  and  the  RS/6000  hold  the  promise  of  increased  penetration  in 
scientific  and  engineering  markets  without  significant  exposure  in  the 
commericial  market. 

Consider  how  RISC/UNIX  open  systems  stack  up  against  SAA  platforms, 
a.  RISC/UNIX  versus  AS/400 

The  following  points  were  made  by  IBM  concerning  UNIX  when  the  AS/ 
400  was  announced  in  1988: 

•  "We've  said  in  the  past  that  our  AIX  (IBM's  version  of  UNIX)  plat- 
form— which  runs  across  the  PS/2,  the  RT  (now  RS)  and  the  System/ 
370 — should  be  the  primary  choice  where  customers  have  UNIX  re- 
quirements such  as  for  federal  government  programs. 

•  "And  that  still  applies. 

•  "But  there's  a  really  important  point  to  consider  in  comparing  the  AIX 
operating  system  with  the  AS/400  operating  system.  That  is  they  repre- 
sent two  totally  different  philosophies. 

•  "AIX  is  the  right  choice  for  companies  whose  primary  requirement  is 
portability  across  multiple  vendors,  and  who  have  an  established  base  of 
UNIX  programmers.. .programmers  who  are  willing  to  build  the  systems 
themselves  and  to  work  with  the  operating  system  to  customize  their 
solutions. 

•  "For  those  customers  who  don't  want  to  get  involved  in  the  internals  of 
an  operating  system...  who  don't  have  large,  expert  computer 

staffs. ..who  operate  in  the  commercial  business  world  where  immediate 
solutions  provide  the  competitive  edge... or  who  need  to  migrate  System/ 
36  and  38  programs... 
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•  "The  high  level  of  integration  on  the  AS/400  makes  it  the  solution  that 
fits  like  it  was  made-to-order.  It's  just  plain  easier  to  learn  and  use."  [3] 

Later,  after  the  AS/400  had  been  announced  for  awhile,  it  was  stated  that 
there  was  no  plan  to  have  UNIX  on  the  AS/400,  but  that  it  could  serve  as  a 
"tightly  integrated  data  server"  for  RS/6000  workstations. 

The  fact  that  the  AS/400  is  the  most  proprietary  of  systems  does  not  seem 
to  have  had  any  impact  on  its  market  in  the  commericial  environment.  It 
is  selling  at  a  rate  of  approximately  $14  billion  per  year,  has  actually 
gained  market  share  in  international  markets,  and  was  one  of  the  few  IBM 
products  to  "make  its  numbers"  during  1991.  Compare  this  with  sales  of 
the  IBM  9370  (with  or  without  AIX)  or  the  RS/6000  in  the  commercial 
market  and  someone  at  IBM  should  be  getting  the  message.  And  perhaps 
they  are — IBM  is  just  beginning  to  market  the  AS/400  as  a  departmental 
processor  in  large  organizations  and  as  a  development  platform. 

b.  RISC/UNIX  versus  PCs/LANs 

In  the  research  conducted  for  Putting  Downsizing  in  Perspective,  IS 
management  rated  PCs  above  RISC/UNIX  systems  for  having  the  best 
"open  architecture."  At  present,  DOS  is  rated  as  easier  to  use  (or  at  least 
more  familiar)  than  UNIX;  and  both  OS/2  2.0  and  Microsoft  Windows 
with  NT  are  promising  to  leapfrog  UNIX  in  terms  of  functionality  in  the 
commericial  client/server  environment.  In  addition,  early  downsizing 
efforts  directed  toward  UNIX  platforms  have  encountered  the  difficulty  of 
having  to  hire  relatively  expensive  UNIX  experts  at  remote  locations. 

IS  management  obviously  feels  more  comfortable  with  PC/LANs  than 
they  do  RISC/UNIX  systems  for  downsizing,  and  this  is  probably  true  of 
end  users  also. 

c.  RISC/UNIX  versus  System/370  Platforms 

UNIX  is  easier  to  use  than  IBM/370  mainstream  operating  systems  (MVS, 
VM,  and  VSE);  and,  in  a  classic  time-sharing  environment,  it  is  also 
substantially  more  cost  effective.  However,  UNIX  does  not  currently  have 
the  functionality  and  robustness  required  for  large  commercial  applica- 
tions, and  all  vendors  have  had  to  extend  their  versions  of  UNIX  when 
competing  in  that  environment.  It  may  be  possible  to  create  a  UNIX  that 
will  compete  directly  with  MVS/ESA,  but  it  will  no  longer  be  UNIX,  and 
it  is  not  Hkely  that  such  a  product  will  ever  come  out  of  the  cooperative 
efforts  of  either  OSF  or  UNIX  International.  As  functionality  and  robust- 
ness increase,  ease  of  use  (even  with  a  GUI)  and  performance  will  de- 
crease. 

Then,  of  course,  there  are  the  critical  issues  of  data  quaHty  and  security. 
We  strongly  urge  that  anyone  concerned  about  these  issues  study  the 
AT&T  Bell  Laboratories  Technical  Journal  (Vol.63  No. 8  Part  2;  October 
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1984)  before  opting  for  a  UNIX  platform;  the  entire  issue  is  devoted  to 
UNIX.  The  matter  will  be  reviewed  in  more  detail  by  INPUT  in  Data 
Quality  and  Security  in  the  Downsizing  Environment,  but  for  now  we  will 
merely  quote  the  following: 

"Such  open  systems  cannot  ever  be  made  secure  in  any  strong  sense;  that 
is,  they  are  unfit  for  applications  involving  classified  government  informa- 
tion, corporate  accounting,  records  relating  to  individual  privacy,  and  the 
like." 

Then,  after  describing  the  £u  (Call  UNIX)  program  as  a  security  disaster, 
another  author  gives  the  following  advice: 

"L  Do  not  use  £U  from  a  machine  that  is  not  trusted. 
"2.  Do  not  use  £y,  to  a  machine  that  is  not  trusted. 
"3o  Do  not  browse  on  the  remote  machine."  [4] 

It  is  not  by  chance  that  major  network  security  intrusions  usually  involve 
UNIX  systems,  and  this  should  be  taken  into  consideration  when  selecting 
applications  to  be  downsized  to  UNIX  platforms  (or,  evidentiy,  before 
communicating  with  other  UNIX  platforms  using  cu). 

The  message  of  SAA  is  that  compliance  will  provide  a  framework  for 
downsizing  and  eliminate  many  of  the  integration  problems  inherent  in 
open  systems.  In  addition,  it  also  promises  connectivity  to  the  open 
systems  world.  Although  public  support  of  SAA  is  negligible  at  present, 
30%  of  respondents  to  INPUT'S  downsizing  study  felt  it  would  be  the 
predominant  architecture  for  commercial  work  by  1995,  and  nearly  60% 
felt  that  would  be  by  1999. 

B  

Top-down  versus  Bottom-up 

One  of  the  less  than  remarkable  discoveries  associated  with  structured 
programming  was  "top-down  design/development."  We  say  less  than 
remarkable  because  the  reaction  of  many  experienced  project  managers 
was:  "Is  there  any  other  way?"  It  is  only  since  the  advent  of  the  personal 
computer  that  there  are  those  who  propose  "bottom-up"  systems  develop- 
ment. 

In  parallel  with  the  trend  toward  downsizing  existing  applications,  there  is 
a  trend  toward  "upsizing"  of  applications  that  were  originated  from  the 
bottom  up  (see  Exhibit  IV-2).  Both  downsizing  and  upsizing  result  in  a 
client/server  architecture  that  focuses  on  minicomputer  (by  INPUT'S 
definition)  servers. 

•  Mainframe  applications  (and  data)  are  being  differentiated  and  down- 
sized to  work  unit  servers  (departmental  processors).  •  • 
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•  Personal  computer  applications  are  being  integrated  and  upsized  to  work 
unit  servers. 


EXHIBIT  IV-2 


Downsizing  and  Upsizing 
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Since  practically  everyone  agrees  that  mainframe  computers 
(superservers)  will  not  disappear  as  downsizing  occurs,  the  result  will  be  a 
three-tiered  network  architecture.  This  has  some  critical  ramifications  for 
downsizing  efforts.  For  example: 

•  If  some  applications  work  is  offloaded  from  mainframes,  but  essential 
data  remain  on  the  superservers,  it  is  probable  that  mainframe  workload 
will  diminish  more  rapidly  than  will  the  supporting  mainframe  cost 
structure  (hardware,  software,  facilides,  personnel,  et  cetera). 

•  This  could  mean  that  cost  recovery  of  the  central  organization  may  be 
difficult  unless  rates  from  the  central  facility  are  increased. 

•  Increased  rates  from  the  central  facility  could  mean  that  initial  cost 
justification  for  the  downsizing  effort  may  prove  to  be  illusory. 
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•  What  all  this  means  is  that  outsourcing  of  central  functions  becomes 
increasingly  attractive  in  a  downsizing  environment. 

In  addition,  as  a  "bottom-up"  upsizing  effort  progresses,  additional  levels 
of  integration  will  be  required  and  will  eventually  result  in  either:  1) 
additional  demands  on  a  central  facility  for  data  base  and  network  man- 
agement support,  or  2)  the  necessity  to  contract  with  an  outside  services 
organization. 

Under  either  downsizing  or  upsizing,  it  appears  that  many  organizations 
will  be  reluctant  to  invest  either  financial  or  human  resources  in  the  care 
and  feeding  of  large  mainframe-oriented  data  centers. 


Client/Server  versus  Cooperative  Processing 

Since  both  top-down  and  bottom-up  systems  development  result  in  a 
client/server  architecture,  it  is  necessary  to  examine  this  rather  loose  term, 
especially  as  it  relates  to  cooperative  processing.  Although  client/server  is 
general  enough  to  encompass  cooperative  processing,  it  is  important  to 
understand  the  different  mind- sets  associated  with  the  terminology. 

The  simplest  distinction  between  the  two  is  that  cooperative  processing  is 
associated  with  the  top-down,  SAA-oriented  school  of  thought,  and  cUent/ 
server  is  associated  with  the  bottom- up,  open  systems  school  of  thought. 
Another  related  distinction  would  be  that  cooperative  processing  places 
emphasis  on  data  base  management  as  the  most  important  element  of  an 
application,  whereas  client/server  places  emphasis  upon  the  display  of 
information  (reporting)  as  the  most  important  element  of  the  application. 
In  other  words,  cooperative  processing  has  the  central  IS  department 
strongly  behind  it,  and  client/server  is  supported  by  advocates  of  end-user 
computing. 

Based  on  past  experience,  good  arguments  can  be  made  for  both  sides. 

•  IS  management  can  rightly  say:  "If  the  data  aren't  any  good,  the  infor- 
mation being  generated  isn't  going  to  be  any  good.  The  garbage  in, 
garbage  out  lesson  is  one  of  the  oldest  in  data  processing." 

•  End  users  can  counter:  "What  good  does  all  the  data  do,  when  the  IS 
department  can't  provide  the  information  we  need  to  run  the  business 
until  after  the  fact?  The  IS  department  just  can't  respond  to  our  needs 
fast  enough  in  a  rapidly  changing  business  environment." 

There  is  truth  in  both  of  these  positions,  and  it  would  be  wise  for  both 
sides  to  recognize  that  effective  downsizing  must  be  a  cooperative  effort — 
regardless  of  terminology  or  past  differences. 
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The  primary  issue  remains  centered  around  data  base  management,  and 
how  tight  or  loose  the  architectural  standards  are  going  to  be  in  a  distrib- 
uted data  base  environment. 

D  

Loosely  versus  Tightly  Integrated  Architectures 

Exhibit  IV-3  relates  the  terms  client/server  and  cooperative  processing  to 
data  and  information  management.  Client/server  is  a  broad  term  capable 
of  being  applied  to  all  three  levels  of  "data  connectivity."  These  levels  of 
connectivity  came  from  a  presentation  by  Dr.  Allan  Scherr  of  IBM  in  the 
late  1980s.  It  was  tided:  "Distributed  Data  in  the  1990s",  and  remains  a 
good  model  of  where  SAA  is  headed  in  terms  of  distributed  data  base 
management. 

1.  Pair-wise  Connections 

Scherr  referred  to  pair-wise  connections  as  "yesterday's  solutions"  and 
they  remain  remarkably  similar  to  the  capabilities  available  in  the  UNIX 
client/server  environment. 

•  Hand-tailored  application-to-application  data  connectivity  can  be  effec- 
tive, but  it  is  expensive. 

•  Virtual  disks  permit  the  sharing  of  DASD,  but  they  do  not  permit  the 
sharing  of  data.  This  results  in  a  great  deal  of  redundant  and  unmanaged 
data  and  enormous  demands  for  disk  space,  but  performance  against 
these  specific  files  is  not  burdened  by  the  overhead  of  a  DBMS. 

•  File  transfer  can  provide  for  bulk  transfer  of  data  between  servers  and 
requesters  (clients).  The  efficiency  of  file  transfer  connectivity  is  a 
function  of  the  percent  of  data  actually  needed  by  the  requester.  The 
potential  for  excessive  demands  upon  the  central  host  and  the  communi- 
cations network  is  substantial  when  inexperienced  end  users  are  in- 
volved. In  addition,  there  is  no  multinode  concurrency;  and  the  result, 
once  again,  is  redundant  and  unmanaged  (and  perhaps  unmanageable) 
data. 

Nevertheless,  file  transfer,  properly  architected,  can  be  all  that  is  needed 
for  many  applications.  This  is  an  extremely  important  consideration  when 
downsizing. 

2.  Architected  Cross-System  File  Models 

Scherr  referred  to  architected  cross-system  file  models  as  "today's  solu- 
tions" and  used  IBM's  Distributed  Data  Management  (DDM)  facility  as  an 
example.  In  the  UNIX  open  systems  environment,  this  is  being  addressed 
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to  varying  degrees,  by  various  DBMS  vendors,  in  various  ways,  with  SQL 
serving  as  a  standard  for  many  implementations.  This  model  has  the 
following  attributes: 

•  It  does  provide  record- at- a- time  access,  thus  avoiding  unnecessary  bulk 
file  transfer. 

•  It  provides  local/remote  transparency  among  servers  at  various  levels. 

•  There  is  concurrency  between  local  and  remote  users — thus  avoiding 
problems  of  data  base  synchronization. 

•  There  is  a  single,  manageable  copy  of  data  with  which  all  users  are 
working. 

•  There  is  a  published  data  connectivity  architecture  upon  which  applica- 
tions can  be  developed. 

Because  of  the  loose  hardware/software/firmware  integration  that  is 
implicit  in  the  UNIX  open  systems  environment,  competing  vendors  offer 
different  architectures  for  data  connectivity  (gateways,  pass-through, 
bridges,  data  models  supported,  etc.).  It  is  reasonable  to  expect  most 
vendors  to  provide  data  connectivity  to  the  SAA  world  at  all  levels — there 
is  just  too  much  of  an  installed  base  to  ignore.  However,  the  integration 
between  SAA  and  the  outside  world  can  never  be  as  tight  as  it  is  within 
the  SAA  world. 

3.  Architected  Cross-System  Data  Base  Models 

Scherr  referred  to  architected  cross-system  data  models  as  "tomorrow's 
solutions."  In  other  words,  this  is  where  SAA  is  heading  in  the  1990s. 
And  where  SAA  is  heading  in  the  1990s  is  toward  distributed  data  base 
management  in  the  broadest  sense  of  the  term,  but  with  a  very  important 
caveat:  be  prepared  to  go  relational  in  a  big  way. 
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Client/Server  versus  Cooperative  Processing 
(Data  and  Information  Management) 

Client/Server 

•  Pair-wise  Connections 

-  Hand-tailored  Application-to-Application 

-  Virtual  Disks 

-  File  Transfer 

Client/Server  ^Potential) 

•  Architected  Cross-System  File  Models 

-  Record-At-a-Time  Access 

-  Local/Remote  Transparency 

-  Concurrency  with  Local/Remote  Users 

-  Manageable  Single  Copy  of  Data 

-  Published  Architecture 

Cooperative  Processing  (SAA) 

•  Architected  Cross-System  Data  Base  Models 

-  For  All  Data  Types 

-  Consistent  SQL  Interfaces 

III          It  f 

-  Consistent  End-User  Interfaces 

-  Data  Administration  Facilities 

•  Data  Description 

•  Security 

•  Recovery 

•  Auditability 

-  Automatic  Data  Conversions 

-  Intersystem  Data  Integrity  and  Recovery 
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The  following  are  the  attributes  of  architected  cross-system  data  base 
models: 

•  The  architecture  will  encompass  all  data  types.  The  significance  of  this 
statement  can  appreciated  by  looking  at  Exhibit  IV-4.  This  is  multime- 
dia integration  in  a  big  way. 

•  There  will  be  consistent  SQL  interfaces  across  SAA  operating  environ- 
ments. 

•  There  will  be  consistent  end-user  interfaces  (within  SAA). 

•  Data  administration  facilities  will  include  the  following: 

-  Data  description 

-  Security  across  systems 

-  Recovery  across  systems 

-  Auditability 

•  There  will  be  automatic  data  conversions  across  systems  (and,  hopefully, 
this  includes  most  of  the  data  types  in  Exhibit  IV-4). 

•  There  will  be  inter  system  data  integrity  and  recovery. 

Scherr  pointed  out  that  System  R*  was  a  prototype  of  such  an 
architectured  cross-system  data  base  model,  but  it  should  be  obvious  that 
what  we  are  talking  about  here  goes  far  beyond  either  System  R*  (a 
follow-on  development  effort  to  System  R  that  was  the  prototype  system 
for  the  relational  model  at  IBM's  San  Jose  laboratory),  or  the  plans  of  any 
other  DBMS  vendor.  For  one  thing,  no  other  vendor  is  prepared  to  pro- 
vide "intersystem  data  integrity  and  recovery"  for  the  tightly  integrated 
SAA  systems  such  as  the  AS/400,  which  has  its  DBMS  and  communica- 
tions system  built  into  its  operating  system  (OS/400). 

In  fact,  this  is  the  critical  architectural  point  that  separates  the  SAA  world 
from  the  open  systems  world:  IBM  has  an  announced  distributed  data  base 
management  strategy  that  is  tightly  integrated  across  the  SAA  platforms. 
In  the  open  systems  world,  there  are  many  competing  DBMSs;  and  they 
all  must  be  prepared  to  interface  with  SAA  systems  already  installed  in  the 
commercial  environment,  and  which  currently  control  the  data  bases  for 
applications  that  may  be  downsized. 
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Types  of  Data  To  Be  Distributed 


•  Records 

■  - 

•  Graphics 

-Accounting 

-Charts 

-  Inventory 

-Maps 

-  Sales 

-Drawings 

•  Text 

•  Images 

-  Notes 

-  Facsimile 

-  Letters 

-Video 

-  Documents 

-Pictures 

•  Voice 

•  Other 

-  Messages 

-  Programs 

-Annotations 

-  Knowledge  Rules 

-Audio  Response 

-  Metadata 

This  results  in  the  following  problem(s)  when  downsizing  to  UNIX-based 
open  systems: 

•  No  competitive  vendor  can  promise  to  provide  "intersystem  data  integ- 
rity and  recovery"  across  the  UNIX/SAA  boundary;  and,  in  most  cases, 
essential  data  bases  to  support  downsized  applications  will  continue  to 
reside  on  SAA  systems. 

•  Of  equal  significance,  IBM  (even  if  it  was  so  inclined)  cannot  promise 
"intersystem  data  integrity  and  recovery"  once  data  are  distributed  to 
"foreign"  systems. 

•  If  anticipated  problems  of  data  quality  and  security  are  the  limiting 
factors  in  downsizing  existing  applications,  those  problems  become 
increasingly  acute  as  one  moves  farther  away  from  the  SAA  world. 
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•  It  certainly  is  not  difficult  to  imagine  IBM  exploiting  fear,  uncertainty 
and  doubt  about  the  quality  of  data  in  the  open  systems  world;  and  there 
is  every  reason  for  its  customers  to  move  cautiously  when  distributing 
data  outside  the  tight  confines  of  the  SAA  world  because  there  are  some 
very  real  technical  problems  with  distributed  data  bases — both  in  the 
SAA  world  and  out  of  it. 

IBM  may  be  moving  slowly  toward  "tomorrow's  solutions,"  but  it  is 
proceeding  according  to  a  published  plan.  The  only  question  is  whether 
IBM  will  succeed  or  fail;  there  are  no  competitive  alternatives  to  reach  the 
goal  IBM  has  set  itself.  It  is  input's  opinion  that  IBM's  customers  and 
its  competitors  have  an  interest  in  seeing  IBM  succeed  in  solving  the 
problems  of  distributed  data  base  management.  It  is  a  necessary  step  in 
the  effective  use  of  rapidly  advancing  information  technology. 

E  ^  

Centralized  versus  Distributed  Data  Bases 

With  all  that  said  about  the  thrust  of  SAA  and  "tomorrow's  solutions"  to 
the  problems  of  distributed  data  base  management,  there  remain  several 
major  questions  concerning  the  necessity  or  desirability  of  distributed  data 
bases.  Who  needs  distributed  data  bases?  Which  applications  require 
distributed  data  bases? 

These  are  legitimate  questions  when  dealing  with  traditional  commercial 
data  records  (see  Exhibit  IV-4).  Many  such  encoded  data  bases  can  be 
legitimately  centralized,  and  some  do  not  even  need  the  "benefit"  of  an 
elaborate  DBMS.  There  are  still  some  applications  that  can  do  very  well 
with  indexed  sequential  files.  Portions  of  these  applications  (data  entry 
and  reporting)  can  be  downsized  to  good  effect,  leaving  the  data  bases 
centralized.  - 

However,  when  we  take  a  look  at  the  probable  future  of  downsized  appli- 
cations, we  are  confronted  with  the  other  data  types  listed  in  Exhibit  IV-4, 
and  these  other  data  types  will,  of  necessity,  result  in  distributed  data 
bases.  Consider  the  following  example: 

•  An  existing  order  entry  system  is  downsized  to  multiple  branch  offices, 
but  a  central  data  base  remains  in  place. 

•  Initially,  the  application  is  split  so  that  all  editing  of  incoming  orders  and 
preparation  of  customer  documents  (including  billing)  is  now  done  in 
each  branch  office,  but  the  data  base  of  record  remains  on  a  host  main- 
frame. 
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•  Assume  that  orders  are  accompanied  by  supporting  documents  which  are 
processed  for  both  financial  reasons  and  technical  feasibility,  and  the 
individual  branch  offices  may  occasionally  call  on  other  organizations 
to  assist  in  the  analysis.  It  is  only  after  the  paper  process  is  completed 
that  the  centralized  data  base  is  updated. 

•  Once  the  application  has  been  downsized,  it  is  determined  that  the  order 
processing  can  be  improved  substantially  by  truncating  the  flow  of  paper 
documents  in  the  mail  room  at  the  branch  office.  It  is  determined  that  an 
image  processing  system  can  expedite  the  routing  of  all  necessary 
"paperwork"  among  organizations.  This  means  that  the  order,  and 
supporting  documents,  can  be  at  several  workstations  and/or  organiza- 
tions simultaneously. 

•  In  addition,  it  is  found  that  an  expert  system  requiring  extensive  analysis 
of  customer  historical  records  can  be  used  to  clear  a  subtantial  portion  of 
the  orders  currently  being  routed  outside  the  branch  for  expert  opinions. 
It  is  decided  to  standardize  on  the  use  of  the  expert  system  for  all 
branches,  and  one  of  the  decision  rules  of  the  expert  system  involves  a 
continuing  assessment  of  time  spent  processing  certain  orders. 

•  As  soon  as  it  is  decided  to  "improve"  the  order  processsing  applications 
with  image  processing  and  expert  systems  capability,  a  distributed  data 
base  is  required.  Moving  all  of  the  document  images  required  for  intra- 
and  interoffice  use  to  a  central  computer  just  doesn't  make  much  sense, 
nor  does  it  make  sense  to  keep  detailed  work  measurement  data  on  a 
remote  computer. 

Downsizing  and  advanced  computer/communications  applications  will 
lead  logically  to  distributed  data  bases  if  we  accept  a  definition  of  data  that 
includes  everything  stored  in  a  computer. 

F  

HLL  versus  CISC  versus  RISC  versus  ASIC 

Though  this  report  is  concerned  specifically  with  systems  architecture  as  it 
relates  to  downsizing,  it  will  not  go  into  a  great  deal  of  technical  detail 
concerning  hardware  architectures.  Suffice  it  to  say  that  there  are  strong 
advocates  of  HLL,  CISC,  and  RISC  among  computer  architects  and 
engineers;  and  it  is  INPUT'S  belief  that  all  three  architectures  have  signifi- 
cant roles  to  play  in  the  downsizing  environment. 

The  CISC  architecture  has  been,  and  continues  to  be,  dominant  in  the 
commercial  data  processing  market.  Applications  built  on  CISC  platforms 
interface  at  various  levels  of  the  computing  system.  [5]  As  mentioned 
earlier,  it  is  difficult  for  applications  programs  (and  software  development 
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personnel)  to  avoid  interfacing  at  all  four  layers  of  the  computer  systems 
architecture.  Exhibit  rV-5.  These  interfaces  are  apparent: 

•  At  the  subsystem  level,  where  the  application  program  depends  upon  a 
DBMS  or  "office"  system  to  support  its  implementation 

•  At  the  network  interface  level,  where  the  application  program  must 
depend  upon  network  control  and  management  facilities  to  connect  to 
the  LAN  and  navigate  the  WAN 

•  At  the  operating  system  level,  where  a  familiarity  with  commands 
remains  essential,  regardless  of  how  much  buffering  is  done  with  a  GUI 

•  Then  when  an  application  programming  language  is  employed,  the 
developer  is  face  to  face  with  the  instruction  set  of  the  computer,  and 
may  even  get  involved  in  "peeking"  and  "poking"  around  at  the  digital 
leveL 

Starting  with  an  IBM  personal  computer  (a  CISC  machine),  downsizing 
developers  are  confronted  with  a  bewildering  array  of  systems  software, 
communications  packages,  networking  systems,  and  applications  enabling 
subsystems.  It  matters  not  whether  the  developers  are  experienced  with 
developing  systems  under  MVS/ESA — just  the  evaluation  process  of 
selecting  the  software  cushioning  to  build  on  the  microprocessor  can  be 
extremely  expensive  and  time  consuming. 

If  one  decides  to  go  with  a  RISC  platform,  the  operating  system  decision 
becomes  relatively  simple:  some  brand  of  UNIX  will  be  the  answer. 
However,  the  multilayered  interfaces  remain,  and  this  can  be  a  problem 
when  downsizing,  because  UNIX  will  not  have  the  functionality  of  the 
mainframe  operating  system.  This  will  increase  the  burden  of  porting  the 
application  to  the  RISC  platform.  Then  there  is  the  RISC  architecture 
itself,  and  what  this  means  in  terms  of  the  downsized  application  is  diffi- 
cult to  say.  Here  is  what  one  computer  scientist  had  to  say  on  the  subject: 

"In  this  area  (the  CISC,  RISC,  HLL  controversy)  there  is  some- 
times more  passion  than  crisp  definition.  A  full  understanding  of 
the  various  trade-offs  in  the  processor  architecture  area  involves  an 
appreciation  not  only  of  architecture,  but  for  design  methodologies, 
underlying  technologies,  and  compiler  methodologies  as  well  as 
for  the  costs  of  hardware  and  software  production  in  different 
technological  intervals.  A  'good  architecture'  (processor  architec- 
ture) should  be  easily  and  efficiently  represented  in  the  technology, 
and  should  provide  for  simple,  efficient  compilation.  But  there 
may  be  other  considerations  whose  importance  becomes  greater 
over  time.  A  serious  problem  is  that  we  lack  a  universally  ac- 
cepted metric  either  for  a  'good  architecture'  (although  many  have 
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been  proposed)  or  for  the  'complexity'  of  a  compiler,  and  we  seem 
certainly  unready  to  deal  with  issues  about  the  quantitative  impact 
an  architecture  should  have  on  the  cost  of  producing  and  maintain- 
ing code,  etc."  [5] 


EXHIBIT  IV-5 
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Thus,  it  can  be  stated  that  the  decision  to  go  from  a  mainframe  CISC 
environment  to  a  RISC/UNIX  environment  is  to  leave  something  that  is 
relatively  well  known,  through  actual  usage  and  measurement,  to  go  to  an 
environment  that  is  highly  speculative  at  best. 

Having  touched  on  the  CISC  and  the  RISC  architectures,  we  also  have  an 
HLL  architecture  to  deal  with — the  AS/400.  This  is  a  machine  with  a 
truly  different  architecture,  which  starts  by  pushing  the  DBMS  and  net- 
work control  funcdons  down  into  the  operating  system — many  functions 
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of  which  have,  in  turn,  been  pushed  down  into  the  machine  architecture 
level.  The  AS/4(X)  has  a  single  address  level  and  was  announced  with  48- 
bit  addressing.  Anyone  who  has  watched  the  struggles  of  the  370  archi- 
tecture machines  to  increase  addressing  through  "extended  architectures" 
will  understand  that  they  just  arrived  at  this  level  along  with  the  AS/4(X). 
Then  shortly  after  announcement  of  the  AS/400,  it  was  stated  that  the 
architecture  could  "easily  accommodate"  64-bit  addressing  if  it  was 
needed  for  "image  processing"  or  large  networkSo 

Though  the  AS/400  remains  enigmatic  to  both  CISC  and  RISC  advocates, 
there  is  considerable  experience  in  implementing  business  applications  on 
these  systems.  One  striking  example  was  the  implementation  of  IBM's 
ImagePlus,  which  was  developed  for  both  the  MVS/ESA  and  OS/400 
platforms.  IBM's  THINK  magazine  [6]  reported  the  following  experience 
with  implementation. 

•  The  MVS/ESA  version  of  ImagePlus  was  reported  to  be  a  "new  ap- 
proach in  systems  development"  and  involved  "standard  IBM  software 
enhanced  by  the  contributions  of  14  IBM  development  laboratories, 
along  with  selected  components  not  part  of  IBM's  current  product  line." 
(The  original  MVS/ESA  version  required  customers  to  have  IMS,  DB2 
and  CICS  installed.)  The  description  of  the  pilot  installation  at  USAA 
was  full  of  qualifiers  such  as  "when  fully  operational"  and  alluded  to  the 
expansion  of  the  system  "over  time." 

•  The  OS/400  version  of  ImagePlus  was  originally  developed  on  the 
System/36  by  a  single  IBM  Advisory  Systems  Engineer  with  the  help  of 
an  IBM  business  partner  in  Sioux  Falls,  SD,  who  wrote  the  necessary 
software  on  a  "tight  deadline  (which  was  met)."  This  system  was 
readily  ported,  without  fanfare,  to  the  radically  different  architecture  of 
the  AS/400  using  plain  vanilla  OS/400.  The  installation  of  the  prototype 
ImagePlus  system  was  reported  in  THINK  as  follows:  "Unlike  the 
USAA  project,  there  was  no  gradual  phase-in  of  the  Citibank  system.. .70 
IBM  image  workstations  were  connected  to  an  ImagePlus  system  and 
went  into  immediate  operation." 

It  seems  to  us  there  is  a  message  here  concerning  the  ease  with  which 
mainframe  applications  may  be  downsized  from  MVS/ESA  platforms  to 
the  AS/400. 

What  about  the  AS/400  compared  to  those  hot  RISC  MIPS  burners?  Well, 
word  is  beginning  to  leak  out  in  the  trade  press  that  UNIX/RISC  machines 
require  approximately  five  times  as  many  processor  cycles  to  complete 
RAMP-C  and  TCP-A  transactions  as  do  AS/400s.  [7]  It  would  seem  that 
the  efficient  compilers  haven't  quite  caught  up  with  the  RISC  architecture 
yet.  Although  we  have  serious  reservations  about  the  reported  numbers  in 
Computerworld,  it  does  makes  one  wonder  just  how  the  two  systems 
would  compare  in  a  real  commercial  application. 
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So,  while  the  jury  is  still  out  on  computer  systems  architectures,  it  is 
probable  there  is  a  right  place  for  all  of  them — including  the  "downsizing" 
of  some  CISC,  RISC,  and  HLL  processor  functions  to  application- specific 
integrated  circuits  (ASICs).  (See  Exhibit  III-l.) 


Conversion,  Restructuring,  Re-engineering 


Although  there  is  great  complexity  involved  in  selecting  applications  to  be 
downsized  and  their  target  hardware/software  platforms,  IS  management 
is  confronted  with  additional  difficult  decisions  concerning  how 
downsizing  should  be  accomplished. 

•  There  are  those  who  advocate  a  quick  conversion  of  the  application  in 
order  to  take  immediate  advantage  of  the  potential  cost  savings  (or 
perhaps  just  to  keep  the  end  users  quiet).  This  sometimes  takes  the  form 
of  letting  the  end-user  department  develop  the  application  and  then  just 
dumping  the  data  on  it.  In  other  cases,  it  could  mean  that  a  mainframe  is 
rolled  out  and  the  new  platform  is  rolled  in  in  its  place. 

•  Then  there  are  others  who  recommend  that  applications  be  restructured 
so  that  certain  functions  and/or  data  are  distributed  and  the  application  is 
then  processed  "cooperatively." 

•  Finally,  some  feel  that  applications  should  be  completely  re-engineered 
to  make  effective  use  of  new  information  technology,  and  to  maximize 
retum  on  investment. 

While  it  is  easy  to  visualize  cases  where  any  one  of  these  approaches 
might  be  best,  it  is  INPUT'S  opinion  that  re-engineering  is  the  best  strat- 
egy for  most  applications.  Downsizing  is  an  appropriate  time  to  improve 
the  systems  development  process  (and  the  resulting  application),  by: 

•  Making  a  commitment  to  quality 

•  Getting  user  involvement  in  the  development  process 

•  Getting  a  broad  spectrum  of  management  involved  and  committed  to  the 
downsizing  effort 

•  Assuring  that  effective  personnel  are  involved  in  downsizing  effort 

For  those  with  a  long  memory,  these  four  elements  are  the  most  important 
ones  in  INPUT'S  "productivity  pyramid"  that  was  developed  during  a 
major  multiclient  study  on  "Improving  the  Productivity  of  Systems  and 
Software  Implementation"  in  1980.  INPUT'S  emphasis  on  "commitment 
to  quality"  is  based  on  its  belief  that  "quick  and  dirty"  systems  seldom  pay 
off,  but  they  do  stay  around  to  haunt  us  for  a  long  time.  Many  mainframe 
applications  that  are  candidates  for  downsizing  fall  into  this  category. 
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They  have  been  maintained  in  a  state  of  deteriorating  quality  for  years  and 
even  decades.  They  should  not  be  foisted  on  end  users  in  this  condition, 
and  users  should  not  be  encouraged  to  do  a  quick  and  dirty  version  of  an 
old  quick  and  dirty  application. 

H  

Implemention  Strategies  and  Tactics? 

Even  after  it  has  been  decided  what  general  approach  is  going  to  be  taken 
in  implementing  a  downsizing  program,  there  remains  the  question  of 
selecting  the  right  tools  to  do  the  job.  Selecting  the  "right  tools"  sat  at  the 
top  of  the  productivity  pyramid,  and  the  point  was  made  that  selecting  the 
right  tools  was  only  important  if  the  base  of  the  pyramid  was  built  on  the 
solid  foundation  outlined  above. 

It  was  also  pointed  out  that  an  abnormal  amount  of  effort  was  spent  in 
selecting  and  using  tools  without  consideration  of  the  more  important 
elements  that  contribute  to  improved  productivity  in  the  system  develop- 
ment process.  The  emphasis  upon  tools  (and  the  search  for  magical 
solutions)  has  only  gotten  worse  since  INPUT'S  1980  study  on  productiv- 
ity. Today,  it  is  practically  impossible  to  hire  a  consulting  firm  that  does 
not  have  its  own  set  of  tools  that  are  supposed  to  solve  the  problem  regard- 
less of  what  the  problem  happens  to  be. 

In  most  cases,  we  do  not  believe  that  an  acceptable  way  to  downsize  an 
application  is  to  run  it  through  a  set  of  CASE  tools  (upper  or  lower)  and 
generate  code  for  another  hardware/software  architecture — regardless  of 
target  platform.  Proper  downsizing  requires  an  applications  architecture 
(lower  case,  not  necessarily  SAA)  that  takes  into  account  the  distribution 
of  both  processing  and  data  over  the  network. 

Detailed  analysis  of  various  implementation  strategies  and  tactics  is 
beyond  the  scope  of  this  study.  However,  INPUT  does  plan  a  report  on 
Methodologies  for  Information  Technology  Downsizing  as  part  of  its 
Downsizing  Program. 
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Downsizing,  Productivity 
and  Effectiveness 

The  previous  chapter  discussed  competing  architectural  concepts  behind 
and  at  the  screen.  INPUT  believes  that  the  management  concepts  and 
motivation  for  downsizing  are  substantially  more  important  than  those 
technical  considerations. 

In  Putting  Downsizing  in  Perspective,  we  used  a  simple  3X3  matrix  to 
depict  network  architecture  and  a  set  of  "performance  levels"  that  encom- 
pass technical  and  management  concerns.  The  fact  that  the  matrix  is 
simple  does  not  mean  that  it  cannot  be  used  to  depict  extremely  complex 
relationships. 

Exhibit  V-1  summarizes  the  major  architectural  trends  of  the  1990s  and 
also  provides  a  structure  for  measuring  the  effective  application  of  infor- 
mation technology. 
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EXHIBIT  V-1 

Architectural  Trends  of  the  1 990s 
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A  

Major  Architectural  Trends 

•  The  major  architectural  trend  of  the  1990s  will  be  the  integration  of 
information  and  knowledge  with  data.  [1]  What  this  means  is: 

-  Most  business  information  is  currently  communicated  and  stored  on 
paper.  During  the  1990s,  there  will  be  a  significant  shift  away  from 
paper  media  in  business  processes  and  toward  electronic  data. 

-  Most  knowledge  is  currendy  communicated  by  human  beings  and 
stored  in  human  brains.  During  the  1990s,  the  trend  toward  the 
capture  (and  communication)  of  human  knowledge  by  means  of 
electronic  media  (data)  will  accelerate. 

-  Image  processing  and  knowledge-based  systems  are  the  tools  for 
implementing  the  integration  of  information  and  knowledge  with  data, 
and  INPUT  believes  downsizing  is  necessary  for  effective  implemen- 
tation of  such  systems. 

•  The  trend  toward  downsizing  business  applications,  which  has  been 
identified  by  our  research,  is  from  large  mainframes  to  cUent/server 
networks.  It  is  our  belief  that  the  servers  associated  with  most  of  these 
downsized  applications  will  fall  into  what  INPUT  defines  as  the  mini- 
computer category.  (2)  The  process  of  downsizing  has  been  identified 
as  one  of  differentiation  through  which  a  part  of  the  system  (network) 
becomes  more  specialized  (i.e.,  the  human  resources  department  now 
has  its  own  computer  system).  We  use  the  term  differentiation  as  it  is 
defined  in  General  System  Theory  [8];  it  is  important  to  understand  what 
that  implies. 

-  Ludwig  von  Bertalanffy  (the  author  of  General  System  Theory) 
describes  the  process  of  differentiation  in  a  living  organism  as  follows 
[9]: 

•  "...during  differentiation  an  organism  passes  from  states  of  lower  to 
higher  heterogeneity. 

•  "...the  transition  is  towards  ever  more  improbable  configurations, 
towards  systems  of  higher  order  and  organization." 

-  If  we  view  the  network  as  an  "organism,"  this  tells  us  that  the  differ- 
entiation process  (downsizing)  will  result  in  more  complexity,  and  the 
need  for  applying  more  human  and/or  machine  "energy"  to  maintain 
the  "improbable  configurations"  and  higher  order  systems  associated 
with  the  resulting  network.  This  will  be  a  key  factor  in  determining 
the  cost  effectiveness  of  downsizing  (differentiation). 
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•  Differentiation  obviously  does  not  stop  at  the  minicomputer  level.  In 
fact,  the  primary  technological  trend  is  toward  finer  and  finer  network 
granularity. 

-  Downsizing  from  mainframes  will  result  in  some  applications  (or 
functions)  being  differentiated  directly  down  to  the  IWS  level.  (3) 

-  Minicomputer  applications  (and  functions)  will  tend  to  gravitate 
toward  the  workstation  level  as  part  of  the  general  differentiation 
process.  (4) 

-  There  are  limits  and  a  paradox  associated  with  the  differentiation 
process. 

•  The  limits  are  imposed  by  the  increased  complexity  of  network  and 
data  base  management  necessary  to  maintain  order  among  these 
"improbable  configurations." 

•  The  paradox  is  that  much  of  the  lure  of  downsizing  has  to  do  with 
the  "simplicity"  of  the  new  platforms  compared  to  the  complexity  of 
the  mainframe  operating  environment. 

•  Associated  with  the  natural  tendency  to  differentiate  is  the  parallel  trend 
of  mechanization,  in  which  parts  of  the  system  perform  a  single  func- 
tion. This  tendency  is  identified  along  with  differentiation  to  IWSs  in 
Exhibit  V-1  [3  and  4],  The  downsizing  of  IWS  functions  to  ASICs 
(Exhibit  III-l)  is  an  even  clearer  example  of  mechanization.  A  few 
words  about  mechanization  are  necessary  at  this  point. 

-  Mechanization  is  reductionists'  ultimate  answer  to  productivity 
problems;  the  best  example  is  an  industrial  engineer  counting 
"therbligs"  in  an  attempt  to  improve  worker  performance. 

-  Though  there  remains  serious  doubt  whether  reductionist  techniques 
such  as  time  and  motion  studies  can  measure  (much  less  improve)  the 
productivity  of  knowledge  workers,  downsizing  will  provide  the 
ability  to  measure  what  knowledge  workers  are  doing  at  increasing 
levels  of  detail.  For  example,  once  tied  into  a  network,  it  will  be 
possible  to  measure  each  keystroke  and  mouse  click  that  an  employee 
produces,  but  this  does  not  measure  the  quality  of  what  is  being 
produced. 

-  It  has  been  our  experience  that  what  can  be  counted  will  be  counted — 
regardless  of  how  accurate  these  measures  may  be  of  true  performance 
(lines  of  code  is  a  good  example). 

-  General  System  Theory  has  its  foundations  in  the  following: 
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•  The  Aristotelian  dictum  of  the  whole  being  more  than  its  parts 

•  Bertalanffy's  profound  observation  that:  "...in  order  to  understand 
an  organized  whole  we  must  know  both  the  parts,  and  the  relations 
between  them.''  (our  emphasis)  [9] 

•  The  need  to  know  the  relations  between  (and  among)  the  parts  of  a 
system  lead  to  the  necessity  for  integration  of  these  parts.  Whether  we 
start  from  the  bottom  or  reach  it  as  a  result  of  downsizing  is  immaterial. 
The  need  to  integrate  IWSs  will  manifest  itself  in  the  "upsizing"  (inte- 
gration) to  client/server  (minicomputer)  environments.  (5) 

•  In  addition,  General  System  Theory  tells  us  that  centralization,  in  which 
a  "leading  part"  develops,  will  also  occur.  The  need  to  integrate  what 
has  been  differentiated  into  "systems  of  higher  order  and  organization" 
will  manifest  itself  in  the  growth  of  a  server(s)  into  a  superserver(s).  (6) 

Therefore,  we  can  conclude  that  differentiation  and  mechanization 
(downsizing)  have  the  inevitable  result  of  creating  more  complex  systems 
that  require  integration  and  centralization  (upsizing).  That  is  the  inherent 
paradox  associated  with  both  long-range  architectural  trends  and  organiza- 
tion theory:  downsizing  will  lead  to  upsizing,  and  decentralization  will 
lead  to  centralization — it  is  written  in  the  stars. 

This  pulsating  network  architecture  (and  management  philosophy)  also 
makes  it  extremely  difficult  to  determine  how  downsizing  will  impact 
performance/productivity  at  all  four  performance  levels  (see  Exhibit  V-1). 

B  

Downsizing  and  Performance  Levels 

The  only  purpose  of  applying  computers  to  business  systems  is  to  either 
"save  money"  or  "make  money" — in  other  words,  to  either  cut  costs  or  to 
gain  competitive  advantage  by  providing  better  products  and/or  services. 
Sometimes  the  "save  money"  school  prefers  to  talk  in  terms  of  improved 
productivity,  but  that  does  not  obscure  the  fact  that  improved  productivity 
means  fewer  workers. 

In  the  factory  environment,  it  is  rather  simple  to  measure  productivity  by 
counting  the  number  of  widgets  produced  per  time  period  or  per  worker. 
When  dealing  with  office  workers  the  task  becomes  considerably  more 
complex;  especially  since  information  technology,  human  beings  and 
organizational  structures  interact  in  highly  unpredictable  ways.  A  number 
of  years  ago,  INPUT  adopted  the  four  performance  levels  proposed  by 
James  H.  Bair  [10]  for  purposes  of  analyzing  productivity  in  the  office 
environment.  These  four  performance  levels — Computer/Communica- 
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tions  Network,  Human/Machine  Dyad,  Work  Unit,  and  Institutional — are 
identified  in  Exhibit  V-1. 

It  is  obvious  that  when  management  invests  in  information  technology 
(PL/1)  some  return  on  that  investment  is  expected  from  improved  produc- 
tivity or  performance  at  the  other  performance  levels.  During  the  1980s, 
substantial  investment  was  made  in  computer  technology  for  offices  with 
the  following  results: 

•  It  has  been  impossible  to  identify  any  significant  correlation  between 
investment  in  information  technology  and  improved  white-collar  pro- 
ductivity at  either  the  human/machine  dyad  (PL/2)  or  work  unit  (PL/3) 
levels. 

•  It  has  been  impossible  to  identify  any  significant  correlation  between 
investment  in  information  technology  and  improved  institutional  perfor- 
mance (PL/4)  as  measured  by  the  "bottom  line." 

•  In  addition,  since  many  American  business  institutions  appeared  to  lose 
competitive  advantage  during  the  1980s  despite  investing  heavily  in 
information  technology,  some  business  executives  and  theorists  are  even 
suggesting  that  the  investment  in  IT  could  have  been  more  effectively 
applied  elsewhere. 

It  is  important  to  recognize  these  general  environmental  factors,  which 
resulted  from  the  experience  of  the  1980s,  when  trying  to  understand  the 
trend  toward  downsizing  during  the  1990s. 

1.  Anticipated  Benefits  and  Consequences  of  Downsizing 

Exhibit  V-2  uses  the  3X3  matrix  to  graphically  present  the  anticipated 
benefits  and  consequences  of  downsizing. 
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EXHIBIT  V-2 


The  Benefits  and  Consequences  of  Downsizing 
(Performance/Productivity) 


Networks     DIK  Performance/ 
PL/1   Quality  Productivity 

a.  Prompting 
Downsizing 


b.  Inhibiting 
Downsizing 


c.  Benefits 
(IS) 


d.  Benefits 
(Vendor) 


2]Sig  nificant  Agreement 


PL/4 
PL/3 
PL/2 


Reduced  costs 


1 

XXX  A 

■    jr    ^     ■  1 

'X  y  y  ■" 

oooo 

Reduced  data  and 
information  quality 


•  More  responsive  to  user 
information  requests 

•  Faster  systems  development 


•  Better  products  and  service 

•  Improved  white-collar  productivity 

•  Better  business  planning  and 
decision  making 

•  Reduced  hardware  and  IS  costs 

•  Improved  bottom  line 

Overwhelming  Agreement 
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a.  Factors  Prompting  Downsizing 

Both  IS  management  and  vendors  agreed  that  the  primary  factors  prompt- 
ing downsizing  were  "lower  information  systems  costs"  and  "better  price/ 
performance  of  hardware"  (see  Exhibit  V-2a).  Both  of  these  factors  are 
obviously  related  to  Performance  Level/1 ,  and  they  indicate  a  "save 
money"  attitude  on  the  part  of  management  that  may  or  may  not  be  di- 
rectly related  to  the  experience  of  the  1980s. 

•  IS  management  rankings  of  relative  importance  dropped  fairly  sharply 
after  these  two  factors,  leaving  cost  savings  alone  as  the  most  important 
reason  for  downsizing.  It  can  be  assumed  that  IS  management's  interest 
in  cutting  back  (or  controlling)  investment  in  information  systems  is 
motivated,  in  no  small  part,  by  the  attitude  of  corporate  management.  It 
can  also  be  assumed  that  corporate  management  would  not  be  interested 
in  cutting  back  investment  in  information  technology  if  it  was  felt  that  it 
could  significantly  improve  productivity/performance  at  other  levels. 

•  Vendors,  while  ranking  "lower  IS  costs"  as  the  most  important  factor, 
considered  two  additional  factors  more  important  than  improved  hard- 
ware price/performance  even  though  that  factor  had  a  relative  impor- 
tance of  88%.  The  other  two  factors  were  "improved  user  service" — 
99%,  and  "user  control" — 95%.  Both  of  these  factors  indicate  dissatis- 
faction with  the  performance  of  the  IS  function  as  an  organization,  and 
indicate  a  management  issue  that  is  equally  important  to  the  technical 
issue. 

In  other  words,  there  is  the  implication  that  the  failure  has  not  been  in 
technology,  but  rather  in  the  centralized  IS  function  that  has  grown  up 
around  the  mainframes.  This  is  an  important  consideration  that  should  not 
be  ignored  by  IS  management.  However,  there  is  something  just  a  little 
perverse  about  this  conclusion,  and  we  shall  examine  that  later. 

b.  Factors  Inhibiting  Downsizing 

Both  IS  management  and  vendors  agreed  that  the  two  most  important 
factors  inhibiting  downsizing  were  "data  quality  problems"  and  the  "cost 
of  reprogramming."  The  former  was  clearly  the  top-ranked  concern  (see 
Exhibit  V-2b).  Though  these  potential  problems  of  data  base  integrity, 
synchronization  and  security  (that  is  the  way  the  questionnaire  was 
phrased)  have  not  prevented  IS  management  from  pursuing  downsizing  in 
some  form,  these  potential  problems  will  determine  how  effective  the 
downsizing  effort  will  be  in  improving  performance/productivity  at  other 
levels. 

In  other  words,  it  is  possible  that  cost  savings  at  the  IS  and  network  per- 
formance levels  could  be  more  than  offset  by  deterioration  of  data  and 
information  quality  within  the  organization.  The  fact  that  both  IS  manage- 
ment and  vendors  agree  on  the  importance  of  this  factor  in  inhibiting 
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downsizing  does  not  mean  that  they  are  equally  concerned  about  the 
severity  of  the  potential  consequences.  For  example,  the  attitude  of  the 
vendors  could  be  that  IS  is  creating  a  big  problem  about  data  quality 
because  IS  wants  to  inhibit  downsizing. 

It  is  important  that  the  real  nature  of  the  data  quality  problem  be  under- 
stood when  downsizing  is  being  planned;  discovering  the  data  quality 
problems  after  downsizing  could  be  disastrous.  The  importance  of  data 
quality  varies  considerably  from  organization  to  organization, 
and  will  be  a  major  factor  in  determining  the  architecture  of  the  resulting 
information  system. 

It  should  also  be  pointed  out  that  deteriorating  data  and  information 
quality  inevitably  has  an  adverse  impact  on  both  individual  and  organiza- 
tional knowledge,  and  knowledge  is  key  to  institutional  success. 

c.  Benefits  Anticipated  by  IS  Management 

After  being  asked  about  specific  downsizing  efforts  they  (or  their  clients) 
had  under  way,  respondents  were  asked  what  they  anticipated  the  primary 
benefits  would  be.  The  questionnaire  was  designed  to  determine  what 
percent  of  respondents  agreed  with  certain  benefits  and  consequences. 
"Significant"  agreement  is  considered  to  be  above  75%,  and  "overwhelm- 
ing" agreement  is  above  85%. 

IS  management  was  not  in  "overwhelming"  agreement  that  any  of  the 
benefits  would  occur  as  the  result  of  downsizing,  and  did  not  "signifi- 
cantly" agree  that  IS  or  hardware  costs  would  be  reduced  even  though 
these  were  the  primary  factors  prompting  downsizing  (see  Exhibit  V-2c). 
The  only  items  on  which  they  were  in  significant  agreement  were: 

•  Improved  responsiveness  to  user  information  requirements 

•  Broader  range  of  choices  (products  and  services) 

•  Faster,  easier  systems  development 

None  of  these  benefits  or  consequences  can  be  directly  related  to  im- 
proved performance/productivity  at  any  of  the  performance  levels.  It  is  a 
passive  response  to  an  important  question.  One  does  not  sense  any  enthu- 
siasm on  the  part  of  IS  management  for  downsizing. 

d.  Benefits  Anticipated  by  Vendors 

Even  discounting  the  natural  enthusiasm  of  vendors,  their  responses  were 
in  striking  contrast  to  IS  management's.  In  addition  to  endorsing  the 
passive  responses  of  IS  management,  vendors  overwhelmingly  supported 
specific  statements  concerned  with  improved  performance/productivity  at 
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all  performance  levels  (Exhibit  V-2d).  By  a  ratio  of  over  5  to  1,  vendors 
are  in  agreement  that  the  following  benefits  will  result  from  downsizing: 

•  Improved  process,  product,  senace  (PL/3) 

•  Improved  white-collar  productivity  (PL/4) 

•  Better  business  planning  and  decisions  (PL/3,  PL/4) 

•  More  effective  use  of  information  technology  (PL/1) 

•  Improved  responsiveness  to  user  information  requirements 

•  Broader  range  of  choices  (products  and  services) 

In  addition,  there  is  significant  agreement  that  the  following  additional 
benefits  or  consequences  will  result: 

•  Substantially  reduced  hardware  costs  (PL/1) 

•  Diminished  role  and  expense  of  the  central  IS  department  (PL/1) 

The  fact  is  that  INPUT'S  research  shows  asreement  that  there  will  be  a 
radical  change  in  information  system.s  (and  technology)  architecture 
during  the  1990s,  but  there  seems  to  be  litde  consensus  among  IS  manage- 
ment and  vendors  as  to  what  the  benefits  and  consequences  will  be 
at  the  various  performance  levels  of  the  organization. 


The  Innovation  Process 

Innovation  has  become  a  popular  term  lately;  and  it  is  difficult  to  argue 
with  the  fact  that  downsizing,  as  a  predominant  architectural  trend  of  the 
1990s,  will  play  an  increasingly  important  role  in  both  the  rate  and  nature 
of  information  systems  innovation.  However,  the  specific  course  that  IS 
innovation  will  take  is  exceptionalh'  complex  and  far  from  settled. 

Before  taking  a  look  at  the  IS  innovation  process,  a  few  profound  observa- 
tions about  innovation  from  the  past  seem  especially  appropriate.[l  1] 

"An  important  scientific  innovation  rarely  makes  its  way  by  gradu- 
ally winning  over  and  convening  its  opponents:  it  rarely  happens 
that  Saul  becomes  Paul.  What  does  happen  is  that  its  opponents 
gradually  die  out  and  that  the  growing  generation  is  familiarized 
with  the  idea  from  the  bednnina."' 

Max  Planck 
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"The  new  always  carries  with  it  the  sense  of  violation,  of  sacrilege. 
What  is  dead  is  sacred;  what  is  new,  that  is,  different,  is  evil, 
dangerous,  or  subversive." 

Henry  Miller 

"A  'new  thinker,'  when  studied  closely,  is  merely  a  man  who  does 
not  know  what  other  people  have  thought." 

F.M.  Colby 

"Sir,  we  must  beware  of  needless  innovation,  especially  when 
guided  by  logic." 

Sir  Winston  Churchill 

The  current  advocates  of  downsizing  would  certainly  agree  with  the 
wisdom  of  the  first  two  quotations  as  they  apply  to  mainframe-oriented, 
central  IS  departments.  However,  they  might  have  some  difficulty  ac- 
knowledging the  wisdom  of  the  other  two.  Therefore,  let  us  point  out: 

•  There  is  little  new  thinking  associated  with  the  tools  and  architectural 
constructs  of  downsizing — even  superficial  study  reveals  that  such 
concepts  have  been  around  for  two  decades  or  more.  It  is  important  to 
recognize  and  understand  why  mainframe  applications  have  been  so 
resistant  to  change;  that  deserves  close  study. 

•  Sir  Winston's  statement  is  more  than  a  dictum  of:  "If  it  works,  don't  fix 
it."  The  wisdom  comes  in  the  qualifier  of  "...especially  when  guided  by 
logic."  It  is  "logical"  to  assume  that  more  processing  power,  at  a 
cheaper  price,  distributed  directly  to  its  point  of  use,  will  result  in  the 
most  cost-effective  application  solutions.  This  is  classic  reductionist 
thinking,  and  it  is  wise  to  "beware"  of  such  thinking  before  blindly 
pursuing  unnecessary  (and  perhaps  unworkable)  innovations  in  network 
architecture. 

With  that  said,  let's  take  a  look  at  the  IS  innovation  process. 
1.  The  Innovation  Process  Model 

Innovation  processes,  from  hybrid  com  to  diesel  locomotives,  have  been 
an  area  of  study  for  years.  Everett  M.  Rogers  produced  a  synthesis  of 
more  than  1,500  such  studies  and  came  up  with  the  innovation  process 
model  presented  in  Exhibit  V-3a.  [12]  It  will  serve  as  a  starting  point  and 
general  framework  for  our  analysis  of  downsizing.  Simply  stated,  practi- 
cally all  innovations  proceed  through  the  following  stages: 

1.  There  is  need  or  problem  identification,  which  prompts  innovation. 

2.  Potential  solutions  for  the  need/problem  are  researched  (both  basic  and 
applied).  And,  Rogers  points  out  that  most  innovations  researched  have 
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been  technological  innovations,  and  these  practically  always  contain  both 
"material"  (hardware)  and  "software"  aspects. 

3.  There  is  a  development  stage  where  the  actual  innovation  occurs  in  the 
form  of  a  working  prototype.  Both  research  and  development  are  charac- 
terized by  uncertainty,  and  Rogers  makes  a  point  that  is  worth  quoting: 

"If  the  adopter  of  an  innovation  is  faced  with  a  high  degree  of 
uncertainty,  the  inventor-developer  of  a  new  idea  must  cope  with 
even  greater  uncertainty.  The  inventor-developer  must  understand 
not  just  his  or  her  problems  (as  an  innovation-adopter  must  do),  but 
also  the  problems  of  various  other  individuals  and  organizations 
who  will  be  the  ultimate  adopters  of  the  innovation  that  he/she  is 
creating." 

4.  There  is  the  commercialization  of  the  innovation,  which  consists  of  the 
production,  manufacturing,  packaging,  marketing  and  distribution  of  a 
product  (or  service)  that  embodies  the  innovation. 

5.  Then  there  is  the  diffusion  and  adoption  process.  The  decision  to 
diffuse  an  innovation  extends  back  to  the  R&D  processes;  adoption  can 
begin  even  before  full  commercialization  (beta  testing,  for  example). 
However,  the  decision  to  diffuse  and  the  rate  of  adoption  obviously  span 
the  commercialization  process  and  are  critical  to  its  success. 

6.  The  fmal  phase  of  Rogers'  innovation  process  model  is  the  conse- 
quences of  the  innovation.  The  original  need/problem  may  or  may  not  be 
solved  by  the  innovation;  and  the  innovation  may  create  new  needs/ 
problems,  which  prompt  a  new  innovation  cycle. 

All  of  this  makes  a  lot  of  sense  and  works  very  well  for  mechanical  tomato 
harvesters,  but  when  we  start  tampering  with  existing  business  information 
systems  (as  downsizing  does)  we  open  up  a  virtual  Pandora's  box  of 
underlying,  interdependent,  innovation  cycles,  starting  with  the  IS  devel- 
opment cycle  itself,  which  adds  another  dimension  to  the  Innovation 
Process  Model  (Exhibit  V-3b). 
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EXHIBIT  V-3 


The  Innovation  Process  Model 
(With  Underlying  Structures) 
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2.  The  Systems  Development  Process 

Without  going  into  a  great  deal  of  detail,  let  us  present  some  well-known 
symptoms  of  the  problems  associated  with  the  IS  development  process. 
These  were  summarized  quite  succinctly  in  a  paper  by  Kalle  Lyytinen 
published  in  ACM  Computing  Surveys.  [13] 

"There  are  many  indications  that  IS  development  is  fraught  with 
recurrent  problems  caused  by  poor,  undisciplined,  and  incomplete 
development  practices.  According  to  a  recent  survey  ...75  percent 
of  all  systems  development  undenaken  was  never  completed  or,  if 
completed,  not  used.  In  a  similar  vein,  ...the  inordinate  amount  of 
total  life-cycle  costs  (70%)  spent  on  systems  "maintenance"  is  a 
symptom  of  poor  development  practice...." 

These  problems  with  major  IS  development  projects  have  been  around  for 
decades,  and  despite  the  expenditure  of  enormous  human  and  machine 
resources  they  remain  with  us  today.  We  have  watched  the  magic  solu- 
tions to  improved  productivity  in  the  software  systems  development 
process  fall  short  of  the  mark  for  over  thirty  years — COBOL,  DBMSs, 
4GLs,  structured  programming,  methodologies,  prototyping... they  have  all 
had  their  share  of  outrageous  claims  and  failed  to  solve  the  fundamental 
problems  identified  by  Lyytinen.  Indeed,  these  fundamental  problems  are 
what  have  made  the  IS  department  vulnerable  to  attack  for  being  unre- 
sponsive to  user  needs  and  problems. 

It  is  the  height  of  optimism,  bordering  on  folly,  to  believe  that  the  rela- 
tional model,  CASE,  object-oriented  programming  and  GUIs  are  going  to 
fare  any  better  when  applied  to  major  development  projects  of  any  com- 
plexity. In  fact,  the  analysis,  selection  and  integration  of  new  tools,  and 
the  time  required  to  make  effective  use  of  them,  may  further  delay  and 
complicate  the  development  process. 

It  is  also  a  fact  that  the  journey  from  hardware  innovation  to  adoption  for 
real  business  apphcations  can  be  a  slow  and  tonuous  one.  One  has  only  to 
track  the  continuing  development  of  the  PS/2  through  operating  systems, 
applications  enabhng  tools,  "real"  applications,  and  data  base  develop- 
ment, down  to  the  current  integration  and  downsizing  efforts,  to  reahze 
that  effective  application  of  information  technology  can  be  a  daunting  task 
indeed. 

However,  since  business  systems  are  composed  of  both  computers  and 
human  beings,  there  are  additional  complexities  involved  in  the  adoption 
and  consequences  of  downsizing  as  it  pertains  to  the  overall  business 
svstems  architecture. 
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3.  Institutional  Culture 

Sociologists  have  long  been  familiar  with  problems  of  cultural  lag.  Some- 
thing as  simple  as  human  resistance  to  the  use  of  a  keyboard  (or  mouse) 
and  the  preference  for  paper  documents  can  slow  adoption  of  new  busi- 
ness systems.  The  Planck  and  Miller  quotes  above  apply  not  only  to  the 
IS  department's  reaction  to  downsizing,  but  to  the  end  users  who  are 
confronted  with  a  substantial  dose  of  "newness"  as  downsizing  is  imple- 
mented. However,  downsizing  does,  in  fact,  seem  to  be  changing  institu- 
tional culture. 

Organizations  once  prided  themselves  on  the  fact  that  executives  answered 
their  own  phones.  Now  humans  in  the  business  world  are  spending  more 
time  "relating"  to  their  computers  than  they  are  with  other  human  beings, 
and  it  is  now  practically  impossible  to  reach  another  human  being  on  the 
telephone  at  the  office. 

On  the  other  hand,  downsizing  will  permit  offices  without  walls — airlines 
are  planning  to  install  telephones  and  fax  machines  for  business  travelers, 
and  with  the  physical  downsizing  of  staff  there  may  be  fewer  people,  but 
they  are  working  longer  hours.  Telecommuting  is  becoming  increasingly 
popular  (and  accepted),  because  it  is  possible  to  buy  a  board  with  modem, 
voice  mail,  and  fax  for  a  few  hundred  dollars  at  your  local  computer  store. 

Downsizing  has  forced  cultural  changes  in  some  businesses  that  would 
have  been  unthinkable  only  a  few  years  ago.  But,  many  of  the  basic 
business  systems  have  remained  essentially  the  same,  and  both  employee 
and  management  thinking  has  not  necessarily  changed  all  that  much. 

4.  Schools  of  Management  Thought 

There  are  various  management  schools  of  thought  about  the  effective  use 
of  information  technology,  and  these  will  determine  how  downsizing 
proceeds  in  the  1990s.  These  schools  of  thought  will  be  used  in  the  next 
section  to  analyze  the  potential  impacts  of  downsizing  on  the  human 
architectural  structure  of  business  systems — at  Performance  Levels  11  and 
III.  They  can  be  briefly  characterized  as  follows  [14]: 

•  The  Management  Theory  School  of  Thought  emphasizes  "scientific" 
management  as  introduced  by  Frederick  Taylor.  It  features  emphasis 
upon  work  simplification  and  cost  control  that  has  characterized  indus- 
trial engineering  in  the  factory.  Technological  downsizing  will  facilitate 
the  application  of  this  school  of  thought  to  the  office  environment.  This 
will  permit  the  reduction  of  staff  by  increasing  productivity  of  individual 
workers. 

•  The  Mechanization  School  of  Thought  emphasizes  the  automation  of 
processes  using  the  tools  of  both  operations  research  and  industrial 
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engineering.  The  routing  and  scheduling  of  work  is  automated  wherever 
possible.  Downsizing  is  a  major  step  toward  the  cost-effective  substitu- 
tion of  electronic  for  paper  media  in  business  processes — an  innovation 
of  major  proportions  in  the  office  environment. 

•  The  Living  Systems  School  of  Thought  believes  the  empowerment  of 
workers  with  information  will  result  in  increased  productivity  in  terms 
of  improved  products  and  services.  Such  empowerment  has  been  a 
consistent  theme  since  the  development  of  personal  computers. 
Downsizing  and  improved  access  to  corporate  data  are  viewed  as  essen- 
tial to  stimulate  the  untapped  creativity  and  potential  of  the  work  force. 

•  The  Intelligent  Systems  School  of  Thought  is  based  on  Simon's  concept 
of  an  "intelligent  artifact"  capable  of  performing  many  functions  at,  or 
beyond,  the  capability  of  human  beings.  This  has  been  a  highly  contro- 
versial school  of  thought  since  the  early  days  of  computers,  feared  by 
many  to  result  in  the  "devaluation  of  the  human  brain."  Downsizing 
holds  the  promise  of  cost  effectively  exploring  both  the  potential  and 
limitations  of  artificial  intelligence  as  a  substitute  for  human  knowledge 
and  decision  making. 

Downsizing  is  an  important  architectural  innovation  for  all  of  the  schools 
of  thought.  However,  the  school  of  thought  that  predominates  in  giving 
impetus  to  current  downsizing  efforts  is  the  Management  Theory  School. 
It  emphasizes  cost  control  of  the  investment  in  both  information  technol- 
ogy and  information  systems  themselves  (PL/1).  Therefore,  the  initial 
measure  of  success  of  downsizing  in  most  companies  will  be  perceived 
reduced  costs  of  information  systems. 

For  that  reason  it  is  important  to  understand  the  cost  factors  associated 
with  downsizing. 

D  

Cost  Factors  To  Be  Considered 

Regardless  of  whether  the  stated  objective  of  downsizing  is  to  reduce  IS 
costs,  the  fact  remains  that  the  emphasis  upon  hardware  price/performance 
and  the  advantages  of  "open  systems"  imply  that  substantial  cost  benefits 
will  result.  And,  as  long  as  the  focus  remains  on  the  central  IS  function,  it 
may  be  possible  to  demonstrate  cost  savings.  Downsizing  to  more  cost- 
effective  platforms  should  reduce  mainframe  workload  (or,  at  the  very 
least,  control  traditional  growth).  In  addition,  the  decentralization  of  some 
IS  responsibiUties  should  lower  central  IS  department  budgets. 

Unfortunately,  there  is  currently  little  reason  to  beheve  that  the  total 
investment  in  information  technology  will  decrease  if  the  overall  costs  of 
downsizing  are  considered.  This  should  be  cause  for  concem  regardless  of 
what  is  prompting  the  downsizing  effort. 
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For  example,  one  organization  that  had  akeady  decentralized  IS  develop- 
ment and  maintenance  responsibilities,  but  continued  to  provide  process- 
ing and  data  base  services  from  a  highly  centralized,  mainframe-oriented, 
data  center  decided  to  develop  an  "information  architecture"  for  the  21st 
century.  Based  on  its  knowledge  and  experience  with  downsizing  tech- 
nologies (an  extensive  network  of  minicomputers  and  workstations  is 
installed),  IS  management  made  two  fundamental  assumptions: 

L  That  the  overall  architecture  would  be  built  on  the  "client/server" 
model 

2.  That  better  applications  development  tools  (including  off-the-shelf 
applications)  would  be  available,  and  used,  in  the  client/server  environ- 
ment 

The  primary  objective  was  not  to  save  money,  because  this  was  a  long- 
range  plan.  However,  even  for  a  long-range  plan,  the  question  of  funding 
arose.  It  was  a  simple  question  of  how  do  we  get  from  where  we  are  to 
where  we  want  to  be?  A  "cost  and  funding  task  force"  was  established 
which  came  up  with  a  comprehensive  framework  for  analyzing  the  relative 
costs  of  client/server  technologies  as  compared  to  mainframe  technology 
(see  Exhibit  V-4). 
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EXHIBIT  V-4 


Downsizing  Cost  Factors 
(Client/Server  versus  IVIainframe) 
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The  cost  factors  and  organizational  entities  form  a  matrix  that  was  used  by 
the  cost  and  funding  task  force  to  take  a  rough  cut  at  determining  whether 
costs  would  go  up  or  down  in  specific  cells.  These  results  are  presented 
for  demonstration  purposes  only  since  they  are  relatively  meaningless 
without  detailed  knowledge  conceming  the  current  information  systems 
infrastructure.  (While  such  detailed  analysis  is  beyond  the  scope  of  this 
study,  INPUT  is  in  the  process  of  preparing  a  set  of  case  studies  that  will 
be  published  in  a  separate  report,  and  this  organization  will  be  included  in 
that  report.)  However,  a  few  observations  will  be  made  in  order  to  clarify 
the  use  of  the  matrix. 

•  The  "Application  Custodian"  refers  to  the  specific  organization  having 
responsibihty  for  the  development  and  maintenance  of  the  applications. 
Although  IS  was  decentralized  several  years  ago,  and  analysts  and 
programmers  were  transferred  to  user  departments,  there  are  certain 
applications  that  remain  the  responsibility  of  the  central  IS  function 
(which  is  associated  with  the  data  center). 

•  The  central  mainframes  are  viewed  as  (super)  servers  for  purposes  of 
planning  the  information  systems  architecture,  and  it  will  be  noticed  that 
costs  of  Data  Center  "servers"  and  environmental s  (space,  air  condition- 
ing, power,  etc.)  are  projected  to  decline. 

•  It  should  also  be  noted  that  costs  of  application  development  and  mainte- 
nance are  projected  to  decline  based  on  the  assumption  of  improved 
tools  and  packages  programs. 

•  On  the  other  hand,  costs  for  systems  software  and  maintaining  data 
quality  are  projected  to  increase,  partially  because  standards  activities 
have  been  weakened  by  decentralization.  (The  subject  organization  had 
standardized  on  a  specific  central  data  base  system,  and  with  downsizing 
they  will  have  new  DBMSs  to  support.) 

•  The  task  force  has  not  yet  determined  whether  the  net  cost  of  moving  to 
the  client/server  environment  will  be  positive  or  negative  on  continuing 
operations,  but  it  was  observed  that — for  this  particular  organization — 
downsizing  transition  costs,  alone,  may  be  high  enough  to  preclude  any 
possibility  of  cost  recovery  over  the  life  of  the  applications. 

The  problems  associated  with  transition  costs  were  described  as  being  a 
"one-time  cost  extending  over  many  years"  during  which  "we  will  need  to 
support  and  operate  in  a  dual  architecture  environment,  both  mainframe 
and  client/server..." 

It  appears  that  downsizing  may  not  result  in  decreased  costs  at  PL/1,  and 
that  funding  from  the  downsizing  effort  may  have  to  be  justified  based  on 
the  other  performance  levels  (see  Exhibits  V-1  and  V-2).  This  could 
require  a  substantial  change  of  management  mind-set  in  many  organiza- 
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tions  where  concentration  on  the  bottom-line  and  quarterly  results  seems 
to  be  the  predominant  management  style. 

In  fact,  it  appears  that  downsizing  may  result  in  substantial  one-time  costs 
that  can  increase  and  extend  over  many  years,  and  even  more  patient 
management  may  fmd  this  unpalatable. 

When  planning  a  significant  information  systems  architectural  innovation, 
it  is  important  to  minimize  the  risk  of  getting  caught  in  the  "dual  architec- 
ture environment"  for  an  extended  period  of  time — especially  when  the 
cost  advantages  of  the  new  architecture  are  questionable  (or  not  easily 
quantifiable). 

It  appears  to  us  that  the  risks  associated  with  downsizing  are  most  critical 
at  the  data  base  server  (minicomputer)  level,  where  competing  solutions 
are  at  various  stages  of  the  innovation  process  and  various  levels  of  the 
systems  development  process.  (Exhibit  V-3.) 

E  

Downsizing  Risk  Analysis 

The  Innovation  Process  model  (Exhibit  V-3a)  can  be  used  to  put 
downsizing  in  general  perspective,  and  the  underlying  Systems  Develop- 
ment model  (Exhibit  V-3b)  can  be  helpful  in  evaluating  the  risk  associated 
with  major  downsizing  efforts. 

1.  The  Needs/Problems  Prompting  Downsizing 

The  needs/problems  giving  impetus  to  downsizing  are  as  follows: 

•  IBM's  mainframe  hardware  architecture  is  old,  tired  and  expensive  in 
terms  of  price/performance.  It  was  not  designed  to  operate  in  a  complex 
network  environment,  and  it  has  evolved  through  several  cycles  of  the 
innovation  process — never  quite  catching  up  with  customer  networking 
requirements. 

•  IBM  systems  software  and  applications  enabling  subsystems  (DBMSs) 
are  complex  and  expensive  in  terms  of  both  cost  and  systems  overhead. 
This  means  that  the  mainline  operating  system  and  DBMSs  cannot  be 
"downsized"  to  more  cost-effective  platforms  at  the  departmental  (work 
unit)  level.  IBM  systems  software  has  been  through  even  more  innova- 
tion cycles  than  the  hardware — slowly  evolving  to  increasing  levels  of 
complexity  which  are  beyond  customer  understanding  and  control. 
Enormous  customer  resources  must  be  expended  to  trudge  the  unhappy, 
uphill  road  that  is  IBM  systems  software. 

•  Customers'  investment  in  programming  for  IBM  mainframes  (predomi- 
nantly COBOL)  has  resulted  in  applications  that  have  been  difficult  to 
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develop  because  of  the  complexity  of  the  hardware/software  platform, 
and  expensive  to  maintain  because  of  the  constant  struggle  to  remain 
current  with  the  latest  systems  software.  These  (COBOL)  application 
programs  are  expensive,  inflexible,  and  unstructured.  They  also  happen 
to  be  indispensable — a  source  of  power,  and  a  barrier  to  change,  for  the 
IS  department. 

•  As  if  the  systems  software  and  applications  programming  investment 
weren't  enough  to  tie  the  customer  to  IBM  mainframes,  customer  data 
bases  implemented  using  IMS  are  expensive,  inflexible,  and  so  struc- 
tured that  they  bind  the  entire  customer  enterprise  to  their  hierarchy  in  a 
deadly  embrace.  Relational  data  bases  (using  DB2),  on  the  other  hand, 
manage  to  give  the  customer  a  certain  degree  of  freedom,  but  the  ransom 
is  extremely  high,  and  the  freedom  is  illusory — even  in  peer-to-peer 
relationships  the  peer  that  possesses  the  data  is  more  equal  than  any 
requester. 

•  For  all  of  the  above  reasons,  most  business  systems  are  "IBM  ori- 
ented"— minor  satellites  circling  around  the  Big  Blue  Data  Source. 

This  celestial  architecture  is  comfortable  for  many  IBM  customers  who 
feel  secure  in  their  orbits  because  of  the  reliability  of  the  central  data 
source.  For  others,  the  Big  Blue  Data  Source  is  more  like  a  black  hole  that 
swallows  up  resources  without  possibility  of  return.  It  is  these  IBM 
customers — frequently  end  users — who  want  "choices"  and  the  freedom 
of  controlling  the  data  and  information  necessary  to  run  their  portion  of 
the  enterprise. 

They  are  beginning  to  be  heard,  and  they  even  managed  to  get  IBM's 
attention.  SAA  was  the  direct  result  of  IBM  customers  demanding  that 
what  goes  up — data,  computer  size,  IS  expense — should  at  least  have  the 
possibility  of  coming  down!   SAA  is  now  muddling  through  another 
innovation  process  cycle — not  nearly  fast  enough  for  many  IBM  custom- 
ers. 

2.  Where  the  Downsizing  "Solutions"  Stand 

Though  SAA  may  be  proceeding  with  less  than  due  speed  toward  the 
objective  of  permitting  applications  and  data  to  seek  their  most  cost- 
effective  level  over  the  IBM  processing  hierarchy,  SAA  does  provide 
architectural  goals  and  objectives  that  have  been  reasonably  well  stated. 
Other  downsizing  "solutions"  leave  open  some  rather  serious  questions  at 
both  the  hardware  and  systems  software  levels  of  the  systems  development 
process  (see  Exhibit  V-3). 

•  RISC  technology  as  an  alternative  to  CISC  for  commercial  applications 
(or  as  distributed  data  base  servers)  has  certainly  reached  the  commer- 
cialization stage  of  the  innovation  process  model,  and  the  decision  to 
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diffuse  this  technology  has  obviously  been  made.  However,  despite 
everything  you  read  in  the  press,  this  technology  has  not  yet  been 
adopted  with  any  enthusiasm  as  a  platform  for  downsizing  major  com- 
mercial applications,  and  INPUT'S  research  indicates  that  IS  manage- 
ment does  not  view  this  technology  with  nearly  as  much  enthusiasm  as 
do  vendors. 

•  At  the  operating  system  level,  UNIX  is  in  much  the  same  situation  as 
RISC  is  at  the  hardware  level.  However,  the  situation  with  UNIX  as  a 
downsizing  solution  is  even  further  complicated  by  the  following  facts: 

-  It  does  not  have  proven  functionality  or  robustness  to  replace  main- 
frame operating  systems. 

-  It  is  still  under  development  by  any  number  of  competing  sources  to 
make  it  an  industrial-strength  product  in  the  commercial  market,  and  it 
obviously  has  gone  through  the  commercialization  stage  of  the  inno- 
vation process  model  to  the  accompaniment  of  more  sound  and  fury 
than  anything  since  COBOL.  However,  there  is  littie  substantive  data 
indicating  it  is  being  adopted  with  any  great  enthusiasm  by  the  rank 
and  file  of  commercial  users. 

-  Proprietary  systems  from  major  computer  vendors  (DEC  and  HP  as 
well  as  IBM)  continue  to  sell  well  in  the  minicomputer  market;  DOS 
Windows  currentiy  controls  the  desktop;  and,  OS/2  EE  may  leapfrog 
UNIX  for  serious  commercial  applications. 

•  The  point  is  that  not  enough  RISCAJNIX  systems  have  penetrated  the 
current  IBM-driven  business  systems  market,  so  it  is  impossible  to 
understand  what  the  consequences  of  downsizing  mainft^ame  applica- 
tions to  such  platforms  would  be — especially  in  terms  of  the  downsizing 
cost  model  presented  in  Exhibit  V-4. 

In  the  meantime,  while  all  of  the  sound  and  fury  about  RISC,  UNIX  and 
open  systems  has  been  going  on,  the  AS/400 — an  HLL  (higher-level 
language)  system  with  a  proprietary  operating  system — has  been  quietiy 
taking  over  the  midrange  commercial  market.  During  the  research  for  this 
study,  IBM  announced  the  AS/400  E-Series,  which  extends  down  into  the 
rWS  price  range  and  well  up  into  the  mainframe  price  range  (prices  range 
from  a  littie  over  $10,000  to  approximately  $900,000).  We  have  no 
intention  of  reviewing  that  announcement  here,  but  we  would  like  to  make 
the  following  points  about  the  AS/400,  which  most  competitors  (including 
those  within  IBM)  either  don't  understand  or  choose  to  ignore: 

•  The  statement  was  made  that  if  IBM  were  to  spin  off  the  AS/400  as  a 
separate  company  it  would  have  revenue  of  nearly  $15  billion  per  year, 
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and  would  be  the  second  largest  computer  company  in  the  world  (after 
its  parent  obviously). 

•  The  AS/400  currently  absorbs  1 1%  of  IBM's  resources,  and  produces: 

-  29%  of  its  revenue,  and 

-  33%  of  its  profit  (we  don't  know  how  this  applied  to  1991) 

•  Fifteen  percent  of  the  AS/400s  are  being  sold  into  accounts  other  than 
those  that  already  have  IBM  System/3X  or  AS/400  equipment  installed. 

•  It  has  been  found  that  the  AS/400  requires  approximately  one-fifth  the 
staff  (systems  programmers,  data  base  administrators,  operadons,  etc.) 
that  an  IBM  mainframe  installation  does  to  support  a  comparable  size 
data  base  and  number  of  users.  (The  actual  numbers  were  for  400  users, 
the  mainframe  staff  required  was  between  20  to  50,  and  the  AS/400 
requirements  were  from  4  to  10.) 

In  addition,  the  announcement  contained  the  following  hardware/software 
components  that  are  especially  pertinent  to  downsizing: 

•  IBM  announced  that  a  version  of  CICS  would  be  made  available  on  the 
AS/400.  Current  AS/400  users  have  neither  the  need  nor  the  desire  for 
CISC  (verified  by  a  show  of  hands  in  the  audience).  The  only  purpose 
would  be  to  make  it  easier  for  IBM  mainframe  customers  to  write  (or 
port)  transaction  processing  applicadons  from  mainframes  to  AS/400s, 
and  to  facilitate  cooperative  processing  among  CICS/ESA,  CICS/400 
and  CICS/0S2.  (However,  delivery  for  CICS/400  is  about  a  year  off.) 

•  A  WORM  (write  once,  read  many)  optical  library  is  available  on  all  but 
the  smallest  model  (E02). 

•  The  Turbo  3  1/2  Disk  Unit  for  the  low-end  systems  (read  LAN  servers) 
has  extraordinary  reliability  (400,000  hours  Mean  Time  Between  Fail- 
ures). 

•  In  addition,  it  was  announced  that,  though  the  OS/400  kernel  would 
remain  closed,  IBM  was  now  emphasizing  "openness"  around  the  kernel 
in  order  to: 

-  "Enable  IBM  and  non-IBM  extensions"  to  OS/400 

-  Permit  "interoperability  among  heterogeneous  systems" 

-  Facilitate  "portability" 

-  Provide  the  following  benefits  for  the  AS/400  and  its  users: 
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•  More  tools  and  applications 

•  Industry  standards  compliance 

•  "Enterprise  integration" 

The  AS/4(X)  will  be  four  years  old  this  summer.  It  has  been  selling  at  a 
rate  slighdy  over  $1  billion  a  month  in  the  business  systems  market.  That 
means  an  installed  base  of  about  $50  billion.  The  AS/400  has  already 
been  through  the  innovation  process  and  has  been  adopted  with  enthusi- 
asm in  the  commercial  market.  The  consequences  are  that  its  satisfied 
customer  base  continues  to  grow. 

3.  Downsizing  Risk  Report  Card 

Commercial  users  looking  for  a  distributed  data  base  server  when  they  are 
downsizing  (and  INPUT  obviously  feels  this  is  the  key  to  successful 
downsizing)  would  seem  to  be  presented  with  a  "no-brainer"  in  selecting 
among  the  various  competing  platforms.  They  can  either  sort  through  a 
hodge-podge  of  relatively  unproven  hardware/software  technologies  and 
try  to  piece  together  a  solution  for  themselves,  or  they  can  select  a  high- 
quality,  proven  product  that  can  even  be  "gift-wrapped"  as  a  Total  System 
Package  (TSP)  including  everything  down  to  media  such  as  blank  tapes 
for  backup  and  paper  for  the  printer. 

Exhibit  V-5  is  a  "Risk  Report  Card"  for  rating  competing  hardware/ 
software  platforms  as  distributed  data  base  servers  when  downsizing 
commercial  applications.  The  "grades"  are  based  on  past  performance, 
and  only  the  AS/400  has  taken  "finals"  and  been  fully  accepted  in  the 
commercial  (office)  environment. 

•  Everyone,  including  Microsoft,  recognizes  that  the  inadequacies  of  DOS 
can't  be  hidden  behind  Windows;  and  Apple  has  thrown  a  $4  billion 
rock  that  could  shatter  even  that  fragile  advantage  on  the  client  side  of 
the  client/server  environment.  DOS- Windows  just  doesn't  pass  muster 
as  a  distributed  data  base  server.  It  was  not  rated  on  applications  soft- 
ware, because  much  of  the  shrink-wrapped  commercial  applications  (as 
opposed  to  tools)  are  of  questionable  value  for  implementing  industrial- 
strength  commercial  applications. 

•  Neither  UNIX  nor  RISC  was  developed  with  the  commercial  market  in 
mind,  and  both  are  a  step  backwards  from  mainframe  hardware/software 
technology.  This  platform  was  not  graded  on  DBMS  because  the  quality 
of  DBMSs  for  this  platform  varies  considerably  and  will  be  a  primary 
factor  in  determining  whether  this  platform  passes  its  final  commercial 
examination.  However,  even  if  it  does  pass,  the  operating  system,  the 
hardware  technology,  and  the  availability  of  commercial  applications 
places  it  in  a  position  of  playing  catch-up  with  a  major  front-runner. 
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EXHIBIT  V-5 


Risk  Report  Card 
(As  Distributed  Data  Server) 
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•  OS/2  EE  is  Linproven  and  has  been  so  slow  out  of  the  starting  blocks  that 
it  is  at  a  serious  disadvantage  as  either  a  cHent  or  server.  However,  it 
has  been  architected  to  work  closely  with  both  MVS/ESA  and  OS/400 
on  the  SAA  side  of  the  house.  Though  OS/2  EE  promises  to  be  better 
than  UNIX  as  a  distributed  data  base  server,  it  falls  far  short  of  the  AS/400 
as  a  distributed  data  base  server  or  as  an  applications  engine  in  the 
downsized  environment.  OS/2  EE  was  not  graded  on  commercial 
applications  availability  for  the  same  reason  that  DOS-Windows 
wasn't — industrial-strength  commercial  applications  are  not  readily 
available,  and  those  that  are  available  vary  widely  in  quality. 

•  The  AS/400  (OS/400)  is  vastly  superior  architecturally  to  either  RISC 
(UNIX)  or  PS/2  (OS/2)  as  a  distributed  data  base  server  and  commercial 
applications  engine.  In  addition,  an  extensive  amount  of  proven  applica- 
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tions  software  is  available  for  the  system,  and  it  has  an  enormous  in- 
stalled base  of  satisfied  customers.  The  primary  impediment  to  its 
success  as  a  downsizing  platform  is  IBM's  longstanding  commitment  to 
mainframe  technology,  SNA  and  customer  hardware/software  "growth." 

The  secondary  impediment  is  the  low  profile  of  the  AS/400  in  the  com- 
puter industry;  practically  everyone  seems  to  believe  that  if  it  is  just 
ignored  it  will  go  away.  For  example,  the  San  Francisco  Chronicle  ran  an 
article  with  the  headline  "IBM  Takes  Lead  on  New  Memory  Chip"  which 
described  the  new  memory  technology  being  employed  in  newly  an- 
nounced AS/400  E-series,  and  never  mentioned  the  AS/400  at  all — much 
less  the  fact  that  it  has  continued  to  prosper  through  several  miserable 
years  for  the  U.S.  economy. 

However,  one  of  the  consequences  of  the  success  of  the  innovative  archi- 
tecture of  the  AS/400  is  that  it  can  no  longer  be  ignored.  With  $50  billion 
worth  of  AS/400  technology  out  there  it  is  going  to  make  its  presence 
felt — within  IBM,  among  its  competitors,  and  perhaps  even  in  the  press. 
It  is  somewhat  like  having  an  elephant  in  the  living  room:  if  you  don't 
know  it  is  there  you  probably  won't  trip  over  it,  but  you  may  get  badly 
trampled. 

Does  the  fact  that  the  AS/400  has  clear  superiority  as  a  distributed  data 
base  server  mean  that  there  is  no  place  for  its  competitors?  Of  course 
not — there  are  applications  (and  portions  of  applications)  that  could 
benefit  from  both  RISC  technology  and  UNIX.  In  fact,  IBM  made  a  point 
that  there  was  no  reason  a  RISC  engine  could  not  be  put  under  the  covers 
of  an  AS/400  if  it  was  needed  in  some  apphcations  (such  as  image  pro- 
cessing). 

RISC  and  UNIX  have  an  important  role  to  play  in  new  applications  and  as 
old  applications  are  re-engineered  during  the  1990s  to  incorporate  artifi- 
cial intelligence,  complex  algorithms  of  operations  research,  and  new 
compute-intensive  mathematics  into  commercial  information  systems. 
However,  the  degree  to  which  such  concepts  are  actually  incorporated  into 
business  systems  will  depend  upon  major  innovations  in  the  "human 
architectures"  associated  with  information  systems — including  changes  in 
management  mind-set. 

The  availabihty  of  OS/2  EE,  vastly  improved  price/performance,  im- 
proved user  interfaces,  and  ready  access  to  high-quality  data  promise  to 
fulfill  expectations  of  improved  white-collar  productivity  as  business 
application  functions  reach  the  desktop.  Not  only  will  the  system  be  an 
excellent  client  in  the  client/server  architecture,  but  it  should  be  adequate 
as  a  server  in  small  work  units.  The  PS/2  and  compatibles  are  the  means 
of  empowering  employees,  and  they  are  absolutely  essential  to  reaching 
the  objectives  of  management  initiatives  in  organizational  downsizing, 
where  span  of  control  increases  as  management  levels  are  eliminated. 
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Organization  and  Management 
Implications  of  Downsizing 


It  is  difficult  to  know  whether  downsizing  is  a  phenomenon  of  technology- 
push  or  technology-pull.  In  other  words,  is  the  availability  of  technology 
pushing  management  toward  new  organizations  and  management  con- 
cepts, or  are  new  management  concepts  and  organizations  pulling  technol- 
ogy toward  new  architectures?  It  is  a  moot  point  under  the  best  of  circum- 
stances. 

However,  the  observation  of  Shoshana  Zuboff  in  her  excellent  book  In  the 
Age  of  the  Smart  Machine  is  not;  here  is  what  she  had  to  say: 

"Technological  developments,  in  the  absence  of  organizational 
innovation,  will  be  assimilated  into  the  status  quo."  [15] 

Ms.  Zuboff  is  quite  correct,  and  she  goes  on  to  describe  a  new  type  of 
workplace  that  centers  around  the  "smart  machine."  Unfortunately,  she 
uses  the  term  "informated"  to  describe  this  new  environment;  but  it  is, 
nonetheless,  an  insightful  description,  and  we  shall  use  it  later. 

The  trouble  with  the  centralization  of  power  that  has  accompanied  main- 
frame computing  and  corporate  data  bases  is  not  that  the  computer  be- 
comes the  focal  point  of  the  organization,  but  that  the  concept  of  a  Chief 
Information  Officer  (CIO)  has  tended  to  put  the  IS  department  in  a  hierar- 
chical relationship  with  the  rest  of  the  organization  and  remove  it  from  the 
mainstream  of  the  enterprise.  It  makes  little  difference  whether  the  com- 
puter "pushed"  this  centralization  or  was  "pulled"  along  by  the  latest 
thinking  of  the  nation's  prestigious  business  schools  that  have  prospered 
without  let-up  since  the  end  of  World  War  II.  CentraUzed  planning  and 
control,  and  computers,  have  formed  an  unholy  alliance  that  is  currendy 
under  attack  from  both  advanced  technological  developments  and  manage- 
ment theory. 

Highly  centralized  information  systems  result  in  several  problems  one  of 
which  has  been  described  as  the  "chimney  problem." 
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A  

The  "Chimney  Problem" 

Ford  Motor  Company  described  its  organizational  structure  as  consisting 
of  tall  chimneys  with  the  only  outlet  for  information  flow  and  problem 
resolution  being  at  the  top  (Exhibit  VI- 1).  When  Ford  nearly  went  bank- 
rupt in  the  early  1980s,  it  was  forced  to  make  far-reaching  management 
changes  throughout  the  organization;  this  set  of  initiatives  has  been  la- 
beled "chimney  breaking." 

Regardless  of  terminology,  deep  hierarchical  organization  structures, 
upward  information  flow  to  feed  corporate  data  bases,  and  rigid  financial 
controls  exercised  through  computerized  business  plans  were  beginning  to 
cause  serious  problems  for  American  business  in  the  early  1980s — just  at 
the  time  when  personal  computers  were  starting  to  appear  on  desktops. 

•  Users  saw  themselves  supplying  endless  reports  and  data  to  corporate 
management;  and  receiving,  in  return,  more  requests  for  data  inter- 
spersed with  budgets  and  "plans." 

•  The  control  mentality  of  corporate  management  trickled  down  to  lower 
level  management,  and  peer-to-peer  professional  contact  was  practically 
unheard  of  in  a  continuing  game  of  one-upmanship  across  organizational 
lines  and  between  organizational  layers. 

•  Design,  engineering,  manufacturing  and  customer  service  personnel 
hardly  talked  to  each  other  at  Ford  except  at  the  highest  levels.  Everyone 
kept  feeding  data  into  the  "system,"  but  each  level  felt  that  nothing  of 
value  ever  came  back  except  tighter  controls  and  rejection  of  anything 
new. 

•  This  attitude  was  not  peculiar  to  Ford — the  same  chafmg  under  corpo- 
rate control  and  planning  was  expressed  at  GE,  which  had  been  domi- 
nated by  a  financial  elite  and  where  auditors  were  the  "elite  of  the  elite." 

Both  Ford  and  GE  transformed  themselves  in  the  1980s. 
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EXHIBIT  VI-1 


The  "Chimney  Problem" 


►  Responses  to  requests  for  information  and  data 


More  requests  for  information  and  data  +  occasional 
budgets  and  plans 

Operational  and  professional  information  flow 
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B_  

The  Ford  Transformation 

Ford  fought  its  way  back  from  the  brink  of  bankruptcy  under  the  leader- 
ship of  Donald  Peterson,  who  managed  to  elicit  the  support  of  all  employ- 
ees by  placing  quality  above  cost  and  breaking  down  the  chimneys.  In  the 
interest  of  quality,  a  worker  could  stop  the  line;  and  a  UAW  representive 
actually  presented  a  union  jacket  to  Peterson  when  he  visited  a  plant.  Ford 
still  doesn't  know  exactly  how  it  accomplished  its  transformation — it  was 
so  desperate  that  initiatives  occurred  at  six  distinct  levels  in  the  organiza- 
tion and  proceeded  in  parallel  and  were  not  documented  as  they  occurred. 
However,  it  is  certain  that  the  corporate  financial  reins  were  loosened,  and 
Ford  started  making  innovations  that  would  have  been  unthinkable  in 
better  times.  Among  the  initiatives  were: 

1.  Strategic  Repositioning 

•  The  product  line  was  repositioned  in  1980  when  the  Detroit  Design 
Center  was  assured  that  new  corporate  management  would  be  receptive 
to  new  ideas.  The  key  product  was  Taurus  (which  was  viewed  as  the 
biggest  gamble  since  Edsall),  and  the  plan  proceeded  despite  the  fact 
that  in  1982  Ford's  cash  reserves  dropped  to  45  days. 

•  Quality  was  established  as  the  number-one  priority  for  the  company  in 
1981. 

2.  Employee  Involvement 

•  Beginning  with  quality  circles,  employee  involvement  (including  regular 
meetings  with  assembly  line  employees)  was  extended  throughout  the 
company  in  the  early  1980s,  and  resulted  in  the  replacement  of  several 
senior  management  personnel  who  just  couldn't  adjust  to  the  changes 
taking  place. 

•  Profit  sharing  was  initiated  with  the  UAW  in  1983,  and  an  employee 
education  fund  was  financed  through  a  5-cent-per-hour-worked  contri- 
bution by  the  company.  (So  many  good  ideas  were  developed  that  the 
employee  involvement  system  became  overloaded.) 

•  By  the  mid-1980s,  employee  involvement  was  described  as  "a  way  of 
life"  at  Ford. 

3.  Synchronization  of  the  Organization 

•  During  1983  a  "Change  Task  Force"  audited  Ford  as  a  "system"  and 
identified  the  "disconnects."  Then  100  workshops  were  conducted 
worldwide  to  address  these  disconnects. 
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•  By  1984  "less  onerous"  financial  systems  had  been  developed  and  the 
functions  decentralized;  shortly  thereafter,  the  budgeting  system  was 
applied  in  a  more  discretionary  fashion. 

•  By  1987,  new  performance  appraisals  included  a  bonus  system  that 
weighted  "teamwork"  at  33%. 

4.  Team  Taurus 

•  The  Taurus  prototype  was  the  basis  for  strategic  repositioning.  Ford 
made  a  decision  to  invest  $3.5  billion  during  1980-85  despite  enormous 
losses  during  the  years  from  1979  through  1981. 

•  Team  Taurus  was  created,  and  in  late  1981,  it  was  directed  to  redesign 
because  of  lower  fuel  prices.  In  the  old  "chimney  environment"  this 
would  have  resulted  in  starting  all  over  and  going  through  all  of  the 
internal  political  wrangling  across  organizational  lines.  Team  Taurus 
was  able  to  take  it  in  stride  and  maintain  momentum. 

•  Input  from  hourly  workers,  insurance  companies  and  repair  shops  was 
fed  into  the  development  process  during  1982.  (Customer  inputs  were 
obtained  during  the  design  phase.) 

•  Taurus  was  introduced  on  schedule  and  under  budget  in  1986  despite  the 
redesign  (which  had  been  dictated  from  above),  and  80%  of  the  key 
components  met  or  exceeded  "best  in  class." 

5.  Chimney  Breaking 

•  In  1981,  Ford  started  to  focus  on  "conflict  management"  across  func- 
tional lines,  and  started  to  conduct  training  sessions. 

•  A  "Blue  Ribbon  Committee"  of  executives — which  cut  across  the 
chimneys — was  formed,  which  was  literally  sequestered  until  the  mem- 
bers came  up  with  a  plan  for  how  they  could  work  together.  (It  later 
evolved  into  an  ad  hoc  committee  to  address  specific  issues,  and  resulted 
in  task  groups  to  resolve  problems  at  the  engineering/manufacturing 
interface  and  in  the  design  approval  process.) 

•  The  management  style  that  developed  from  breaking  down  the  chimneys 
was  one  of  contention  management — letting  the  problems  surface  at  the 
working  level  and  providing  a  means  of  resolution. 

•  By  1986  an  "aggressive  plan"  to  rotate  managers  across  functional 
disciplines  had  been  developed,  and  executive  "re-education"  became 
the  watchword. 

•  By  1987  the  various  committees  and  task  forces  had  evolved  into  a 
"Concept  to  Customer  Committee" — and  that  is  how  the  chimneys 
crumbled. 
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6.  Vision  and  Values 

•  In  1979,  Ford  was  rated  worst  in  quality  and  styling  in  the  auto  industry. 
In  the  early  1980s,  based  on  the  strategic  redirection  toward  quality  (and 
in  the  middle  of  some  very  bad  financial  results),  Ford  closed  an  entire 
plant  (Mahwah,  NJ.)  because  of  quality  problems — -establishing  proof 
of  commitment  to  quality  and  a  change  of  values  for  the  company. 

•  By  1981,  white-collar  "chimney  breaking"  activities  and  the  employee 
involvement  program  were  generating  confusion  about  corporate  values. 
The  old  "rules"  no  longer  applied — Ford  was  at  the  beginning  of  a 
cultural  revolution. 

•  In  1982  and  1983,  Donald  Peterson  worked  on  Ford  policy  and  how  to 
articulate  the  company's  new  values,  and  Henry  Ford  n  presented  the 
Mission,  Values  and  Guiding  Principles  of  the  company  at  a  public 
meeting.  The  values,  simply  stated  were: 

-  People — Our  people  are  the  source  of  our  strength.  They  provide  our 
corporate  intelligence  and  determine  our  reputation  and  vitality. 
Involvement  and  teamwork  are  our  core  human  values. 

-  Products — Our  products  are  the  end  result  of  our  efforts,  and  they 
should  be  the  best  in  serving  customers  worldwide.  As  our  products 
are  viewed,  so  are  we  viewed. 

-  Profits — Profits  are  the  ultimate  measure  of  how  efficiently  we  pro- 
vide customers  with  the  best  products  for  their  needs.  Profits  are 
required  to  survive  and  grow. 

•  By  1986,  Peterson  had  added  "Continuous  Learning"  as  a  value — a  step 
that  was  obviously  necessary  to  support  the  original  three  values. 

INPUT  suggests  that  downsizing  is  a  major  innovation  that  is  taking  place 
during  critical  times  for  many  business  enterprises,  and  that  one  of  the 
major  purposes  is  to  break  down  the  walls  between  the  IS  function  and 
operating  departments.  There  are  many  lessons  to  be  learned  from  Ford's 
experience  that  can  be  applied  directly  to  current  downsizing  efforts. 


The  GE  Transformation 

Unlike  Ford,  GE  accomplished  its  transformation  primarily  through  the 
sheer  will  of  Jack  Welch,  who  had  successfully  managed  several  GE 
business  units  despite  the  burdensome  financial  controls.  When  he  be- 
came CEO,  he  cut  the  corporate  staff  back  drastically.  Here  is  what  he  has 
to  say  about  organization: 
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"We  took  out  management  layers.  Layers  hide  weaknesses.  Layers  mask 
mediocrity.  I  firmly  believe  that  an  overburdened,  overstretched  executive 
is  the  best  executive  because  he  or  she  doesn't  have  the  time  to  meddle,  to 
deal  in  trivia,  to  bother  people.  Remember  the  theory  that  a  manager 
should  have  no  more  than  six  or  seven  direct  reports?  I  say  the  right 
number  is  closer  to  ten  or  fifteen.  This  way  you  have  no  choice  but  to  let 
people  flex  their  muscles,  let  them  grow  and  mature.  With  ten  or  fifteen 
reports,  a  leader  can  focus  only  on  the  big  important  issues,  not  on  minu- 
tiae. 

"We  also  reduced  the  corporate  staff.  Headquarters  can  be  the  bane  of 
corporate  America.  It  can  strangle,  choke,  delay,  and  create  insecurity.... 
We  don't  need  the  questioners  and  the  checkers,  the  nitpickers  who  bog 
down  the  process,  people  whose  only  role  is  to  second  guess  and  kibitz, 
the  people  who  clog  communication  inside  the  company.  This  is  a  mind- 
set change:  staff  essentially  reports  to  the  field  rather  than  the  other  way 
around."  [16] 

It  is  input's  belief  that  Jack  Welch's  attitude  is  prevalent  in  American 
business  today,  and  that  the  problems  Welch  deplored  existed  before  the 
current  recession.  Centralized  planning  and  control,  organizational  "chim- 
neys" and  layers  of  management  that  stifle  the  free  flow  of  information  are 
seen  as  the  "problem."  To  the  degree  that  the  central  IS  function  is  associ- 
ated with  the  corporate  hierarchy,  it  has  been  designated  as  part  of  the 
problem.  In  fact,  since  the  term  "information"  has  been  bandied  about  so 
freely,  and  IS  hasn't  been  responsive  to  end-user  demands  for  information, 
the  IS  department  may  be  burdened  with  the  lion's  share  of  the  responsi- 
bility for  the  communication  problems. 

At  any  rate,  there  is  downsizing  going  on  in  corporate  America  that  has 
little  to  do  with  the  availability  of  more  MIPS  on  a  chip.  The  impact  on 
the  role  of  the  IS  department  is  already  beginning  to  be  felt.  A  recent 
issue  of  Computerworld  had  an  article  titled:  "When  The  CIO  Becomes 
Expendable."  It  lists  four  companies  in  which  IS  "chiefs"  (CIOs)  have 
been  downgraded  from  the  Vice  President  level  to  Director  or  Manager. 
[17] 

With  that  in  mind,  let's  retum  to  Dr.  Zuboff  and  her  observations  concern- 
ing the  management  and  organization  changes  that  may  occur  in  "the  age 
of  the  smart  machine." 

P  

Concentric  Ring  Management  and  Organization 

Though  we  deplore  some  of  Dr.  Zuboff  s  terminology,  her  conclusions  are 
based  on  actual  case  studies  (she  teaches  at  Harvard  Business  School)  and 
they  are  extremely  perceptive  of  some  of  the  changes  that  are  going  on 
"beyond  the  screen"  of  technology.  Her  book  was  selected  as  one  of  the 
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10  Best  Business  Books  in  1988  by  Business  Week.  It  provides  some 
important  insights  into  both  management  and  organization  in  the 
"informated"  organization,  and  also  defines  the  future  role  of  what  we 
now  call  the  IS  department. 

Dr.  Zuboff  believes  that  organization  in  the  "informated"  business  enter- 
prise can  best  be  pictured  as  a  set  of  concentric  circles  rather  than  as 
classic  lines  and  boxes.  This  alone  can  be  enough  to  startle  an  IS  profes- 
sional who  has  been  dealing  with  classic  flow  charts  and  the  hierarchical 
data  model,  or  a  corporate  controller  who  is  concerned  with  establishing 
an  audit  trail  and  tight  cost  controls.  Here  is  how  Dr.  Zuboff  describes  it: 

"As  the  intellective  skill  base  becomes  the  organization's  most 
precious  resource,  managerial  roles  must  function  to  enhance  its 
quality.  Members  can  be  thought  of  as  being  arrayed  in  concentric 
circles  around  a  central  core,  which  is  the  electronic  data  base. 
The  skills  required  by  those  at  the  core  do  not  differ  in  kind  from 
those  required  at  a  greater  distance  from  the  core.  Instead  of 
striking  phenomenological  differences  in  the  work  that  people  do, 
the  distance  of  any  given  role  from  the  center  denotes  the  range 
and  comprehensiveness  of  responsibilities,  the  time  frame  of  those 
responsibilities,  and  the  degree  of  accountability  for  cross-func- 
tional integration  attached  to  the  role.  The  data  base  may  be 
accessed  from  any  ring  in  the  circle,  though  data  can  be  formatted 
and  analyzed  in  ways  that  are  most  appropriate  to  the  information 
needs  of  any  particular  ring  of  responsibility." 

We  interpret  the  "intellective  skill  base"  to  be  the  combination  of  informa- 
tion and  knowledge  that  has  been  captured  in  the  electronic  data  base,  and 
the  unique  and  uncaptured  knowledge  of  the  humans  at  the  human/ma- 
chine dyad. 

The  rings  around  the  core  (Exhibit  VI-2)  can  be  described  as  follows: 

1.  Closest  to  the  core  are  the  workers  who  work  directly  with  "informa- 
tion" (data)  on  a  real-time  basis.  They  are  the  daily  production  workers  (at 
all  levels)  who  input,  organize  and  administer  the  central  electronic  data 
base.  Zuboff  states:  "Because  intellective  skill  is  relevant  to  the  work  of 
each  ring  of  responsibility,  the  skills  of  those  who  manage  daily  operations 
form  an  appropriate  basis  for  their  progression  into  roles  with  more  com- 
prehensive responsibilities."  The  operator  at  the  human/machine  dyad  is 
considered  a  "manager"  of  the  core  data  base. 

2.  The  next  ring  of  management  responsibility  is  concerned  with  "intel- 
lective skill  development."  This  implies  both  "high-order  analysis  and 
conceptualization,  as  well  as  in  promoting  learning  and  skill  development 
among  those  with  operational  responsibilities."  This  goes  beyond  the 
classic  training  function,  and  can  be  viewed  as  knowledge  base  manage- 
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ment.  It  looks  "beyond  the  screen"  to  promote  not  only  an  improved  data 
base  interaction,  but  an  improved  distributed  knowledge  base  among  the 
humans  at  the  human/machine  dyad.  Zuboff  puts  it  this  way:  "In  this 
domain,  managers  are  responsible  for  task-related  leaming,  for  learning 
about  leaming,  and  for  educating  others  in  each  of  the  other  three  do- 
mains." 

3.  Beyond  the  intellective  skill  development  ring  is  the  "technology 
development"  ring,  which  will  sound  familiar  to  those  in  IS  departments. 
Zuboff  states:  "This  managerial  domain  of  technology-related  activity 
comprises  a  hierarchy  of  responsibilities  in  addition  to  those  tasks  nor- 
mally associated  with  systems  engineering,  development,  and  mainte- 
nance. It  includes  maintaining  the  reliability  of  the  data  base  while  im- 
proving its  breadth  and  quality,  developing  approaches  to  system  design 
that  support  an  informating  strategy,  and  scanning  technical  innovations 
that  can  lead  to  new  informating  opportunities.  Members  with  the  respon- 
sibility for  the  development  of  technology  must  be  concerned  with  the  use 
of  technology... Technology  develops  as  a  reflection  of  the  informating 
strategy  and  provides  the  material  infrastructure  of  the  leaming  environ- 
ment" 

4.  The  "leaming  environment"  created,  maintained  and  extended  by  the 
inner  rings  of  the  organization  support  "strategy  formulation"  and  "social 
system  development"  rings.  At  this  point,  it  becomes  clear  that  what 
Zuboff  is  describing  is  the  "Living  System"  School  of  Thought  Here  is 
what  she  has  to  say: 

"For  an  organization  to  pursue  an  informating  strategy,  it  must 
maximize  its  own  ability  to  learn  and  explore  the  implications  of 
that  leaming  for  its  long-range  plans  with  respect  to  markets, 
product  development,  new  sources  of  comparative  advantage,  et 
cetera.  A  division  of  leaming  that  supports  an  informating  strategy 
results  in  a  distribution  of  knowledge  and  authority  that  enables  a 
wide  range  of  members  to  contribute  to  these  activities.  Still,  some 
members  will  need  to  guide  and  coordinate  leaming  efforts  in 
order  to  lead  an  assessment  of  strategic  altematives  and  to  focus 
organizational  intelligence  in  areas  of  strategic  value.  These 
managers  lead  the  organization  in  a  way  that  allows  members  to 
participate  in  defining  purpose  and  in  supporting  the  direction  of 
long-range  planning." 

It  is  obvious  that  the  "Living  System"  envisioned  by  Zuboff  breaks  down 
the  conventional  hierarchical  model  of  management,  and  that  the  creation 
of  a  leaming  environment  (organization)  that  empowers  all  employees 
provides  for  both  horizontal  and  vertical  organizational  integration — 
without  clear  lines  between  the  concentric  circles. 
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It  seems  obvious  that  the  Ford  transformation  during  the  1980s  headed 
toward  the  Zuboff  concept  of  concentric  rings  of  management.  The 
statement  of  values  issued  by  Petersen  and  Henry  Ford  n  late  in  the  1980s 
is  a  very  clear  example  of  the  outer  ring  of  "social  system  development." 
While  it  is  probable  that  Zuboff  was  well  aware  of  Ford's  experience,  it 
does  not  appear  that  Ford  was  one  of  the  case-study  companies  upon 
which  she  based  her  book. 

Zuboff  s  contribution  is  in  placing  the  central  data  base  at  the  core  of  the 
organization,  and  in  depicting  the  fluid  management  structure  as  one  of 
concentric  circles  rather  than  as  a  hierarchical  structure  or  even  a  matrix. 
See  Exhibit  VI-2. 

The  implied  flexibility  of  such  an  organization  and  management  style  does 
not  lend  itself  to  either  highly  structured  data  bases  or  slow  response  times 
from  central  IS  to  effect  what  appear  to  be  modest  changes  in  direction. 
For  example,  imagine  the  furor  at  Ford  if  the  great  ideas  formulated 
through  Employee  Involvement  could  not  be  processed  or  implemented 
because  information  was  not  available,  or  Team  Taurus  could  not  be 
formed  because  the  hierarchical  data  base  could  not  be  changed  to  account 
for  it. 
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EXHIBIT  VI-2 


The  Shape  of  the  Future? 
("Intellective"  Skill  Base) 
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E  

Downsizing  and  the  "Intellective"  Skill  Base 

The  core  of  the  "intellective"  skill  base  is  assumed  to  be  a  reliable  elec- 
tronic data  base  (including  all  of  the  data  types  previously  mentioned),  and 
its  importance  to  the  new  management  directions  cannot  be  overstated. 

It  matters  not  whether  this  is  the  infamous  corporate  data  base  that  users 
are  demanding  access  to  for  purposes  of  "strategy  formulation"  or  "social 
system  development"  or  whether  it  is  the  network  distributed  data  base 
that  appears  to  be  the  inevitable  result  of  these  demands.  The  data  base 
must  have  integrity,  and  be  secure  against  intrusion  (or  sabotage)  if  it  is  to 
be  the  core  of  the  "intellective"  skill  base. 

As  we  have  so  carefully  pointed  out  during  the  course  of  our  analysis  of 
downsizing,  there  are  problems  of  distributed  data  base  management 
inherent  in  downsizing  that  have  not  been  solved  by  any  vendor  or  set  of 
vendors.  Where  downsizing  is  proceeding  without  awareness  of  (or 
sensitivity  to)  these  problems,  systems  integrators  are  left  with  the  daunt- 
ing task  of  scheduling  inventions  to  mitigate  the  consequences  of  manage- 
ment demands  for  quality  data  and  information. 

Whether  the  management  mind- set  prompting  downsizing  is  cost  reduc- 
tion through  the  elimination  of  management  layers  or  establishing  a 
learning  environment  on  the  road  to  the  "informated  organization,"  there 
are  going  to  be  substantial  demands  made  on  the  "technology  develop- 
ment" ring  of  the  concentric  management  structure.  That  is  true  regardless 
of  whether  the  CIO  is  demoted  to  manager,  or  whether  those  responsible 
for  "strategy  formulation"  must  spend  a  substantial  portion  of  their  time 
on  technology  development. 

The  dispersing  of  the  central  IS  function  out  into  the  rings  of  the  new 
organization  could  have  the  effect  of  being  an  excellent  learning  experi- 
ence, or  it  could  lead  to  some  unfortunate  consequences.  For  example,  the 
organization  that  developed  the  cost  model  in  Exhibit  V-4  decentralized 
the  IS  function  a  number  of  years  ago,  and  user  departments  are  finding 
that  "their  IS  employees"  have  considerably  less  time  to  devote  to  devel- 
opment activities  because  they  are  directly  exposed  to  ad  hoc  reporting 
requests  and  consulting  assignments  with  end  users. 

The  impacts  of  both  technological  and  management  downsizing  on  IS 
departments,  user  departments  and  vendors  are  highly  unpredictable. 
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The  Challenges  and 
Opportunities  of  Downsizing 

In  this  section,  we  will  explore  briefly  the  challenges  and  opportunities 
that  downsizing  presents  for  corporate  executives,  IS  management,  IS 
users  and  IS  vendors.  We  will  start  with  a  challenge  attributed  to  the  late 
Konosuke  Matsushita  (founder  of  Matsushita  Electric,  Ltd.)  by  Richard 
Tanner  Pascale  in  his  excellent  book  Managing  on  the  Edge  [16]: 

"We  are  going  to  win  and  the  industrial  West  is  going  to  lose  out; 
there's  not  much  you  can  do  about  it  because  the  reasons  for  your 
failure  are  within  yourselves.  Your  firms  are  built  on  the  Taylor 
model.  Even  worse,  so  are  your  heads.  With  your  bosses  doing 
the  thinking  while  the  workers  wield  the  screwdrivers,  you're 
convinced  deep  down  that  this  is  the  right  way  to  run  a  business. 
For  you  the  essence  of  management  is  getting  the  ideas  out  of  the 
heads  of  the  bosses  and  into  the  hands  of  labor. 

We  are  beyond  your  mindset.  Business,  we  know,  is  now  so 
complex  and  difficult,  the  survival  of  firms  so  hazardous  in  an 
environment  increasingly  unpredictable,  competitive  and  fraught 
with  danger,  that  their  continued  existence  depends  on  the  day-to- 
day mobilization  of  every  ounce  of  intelligence." 

The  "Taylor  model"  Matsushita  referred  to  is  based  on  Taylor's  expressed 
opinion,  over  sixty  years  ago,  that: 

"Hardly  a  competent  workman  can  be  found  who  does  not  devote  a 
considerable  amount  of  time  to  studying  just  how  slowly  he  can 
work  and  still  convince  his  employer  that  he  is  going  at  a  good 
pace.  Under  our  system  (Scientific  Management)  a  worker  is  told 
just  what  he  is  to  do  and  how  he  is  to  do  it.  Any  improvement  he 
makes  upon  the  orders  given  him  is  fatal  to  his  success."  [18] 

We  do  not  intend  to  argue  whether  or  not  Matsushita  is  correct  in  his 
analysis  of  the  mind-set  of  the  industrial  West  (much  less  get  embroiled  in 
current  controversies  concerning  worker  quality  and  executive  compensa- 
tion). However,  we  will  say  that  technological  downsizing  supports  both 
the  Matsushita  and  the  Taylor  management  philosophies. 
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*  Microprocessor  technology  can  theoretically  provide  workers  with  ready 
access  to  information,  encourage  active  participation  in  knowledge- 
based  systems,  and  create  an  environment  of  continuous  learning.  Each 
employee  can  contribute  and  be  recognized  and  rewarded  on  the  basis  of 
individual  merit  by  an  objective,  and  perhaps  even  sympathetic,  "sys- 
tem" that  rewards  performance  and  learning  without  regard  to  race,  sex, 
age,  national  origin,  educational  credentials,  personal  appearance, 
physical  handicaps,  political  orientation,  family  connections,  or  position 
in  any  remaining  organizational  hierarchy. 

•  Or,  on  the  other  hand,  the  "easy  to  use"  personal  computer,  complete 
with  GUI,  can  be  used  to  tell  the  worker  what  to  do  in  the  simplest 
possible  terms,  monitor  exactly  how  he/she  is  doing  it,  and  tolerate  no 
deviation  from  prescribed  procedures.  In  fact,  notebook  computers, 
cellular  phones  and  beepers  (two  way)  can  be  used  to  track  and  monitor 
employees  outside  the  office  and  even  into  their  homeSc  Downsizing 
carried  to  extremes  can  mean  system  architectures  that  serve  as  elec- 
tronic chains  to  bind  workers  to  their  employers  24  hours  a  day,  every 
day,  until  they  have  been  sucked  dry  of  all  their  physical  and  mental 
energy.  At  which  time,  their  electronic  personnel  folders  can  be 
"dragged"  over  to  the  garbage  can  icon.  (A  scenario  beyond  the  dreams 
of  either  Frederick  Taylor  or  George  Orwell.) 

These  best  and  worst  of  all  possible  world  scenarios  have  been  around 
since  the  early  days  of  computing.  No  one  said  it  any  earlier  or  any  better 
than  Norbert  Wiener  as  he  worried  about  the  relationship  at  the  human/ 
machine  dyad  in  the  early  days  of  computers. 

"This  new  development  has  unbounded  possibilities  for  good  and 
for  evil... The  first  industrial  revolution,  the  revolution  of  the  'dark 
Satanic  mills,'  was  the  devaluation  of  the  human  arm  by  the  com- 
petition of  machinery.. .The  modern  industrial  revolution  is  simi- 
larly bound  to  devalue  the  human  brain  at  least  in  its  simpler  and 
more  routine  decisions."  [19] 

Wiener's  concern  was  not  restricted  to  fear  of  management  mind-set  and 
intent;  it  also  focused  on  the  inadvertent  loss  of  control:  "By  the  very 
slowness  of  our  human  actions,  effective  control  of  our  machines  may  be 
nullified...."  [19] 

While  the  technical  challenge  of  getting  heterogeneous  computer  systems 
to  talk  with  each  other  occupies  a  great  deal  of  our  attention  in  the 
downsizing  environment,  the  human  side  provides  even  more  of  a  chal- 
lenge. Here  is  the  type  of  finger-snapping  advice  that  is  being  given  to 
business  organizations  by  the  financial  community  (in  this  case  a  Silicon 
Valley  venture  capitalist). 
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"The  virtual  corporation  will  eliminate  middle  management  and 
replace  it  with  trained  workers  operating  computers  to  provide 
information  Hnks  and  help  make  decisions."  [20] 

It  is  doubtful  whether  the  venture  capitalist  either  understands  or  cares 
about  problems  of  distributed  data  base  management,  decision  support 
systems,  management  mind-sets,  "informated"  organizations,  or  the  long 
tortuous  history  of  artificial  intelligence — much  less  Norbert  Wiener's 
concerns  about  "devaluing  the  human  brain."  He  has  a  vision  of  "virtual 
corporations"  that  can  produce  an  infinite  variety  of  custom  products  to 
meet  fluctuating  demands  and  competition  all  around  the  global  village. 

Those  associated  with  the  computer  industry  have  consistently  overrated 
the  benefits  of  technology,  underestimated  difficulties  of  implementation, 
and  failed  to  consider  the  possible  adverse  consequences  of  new  technol- 
ogy. To  visualize  the  architecture  of  a  virtual  corporation  is  one  thing,  but 
to  build  virtual  corporations  without  regard  for  the  realities  of  technologi- 
cal and  human  capabilities  and  limitations  would  be  the  height  of  folly. 

The  primary  challenge  of  the  1990s — for  everyone — is  to  assure  that  a 
proper  balance  is  achieved  (or  maintained)  between  the  human  and  ma- 
chine sides  of  the  information  systems  architecture.  This  requires  an 
objective  and  realistic  appraisal  of  the  capabilities  of  both  technology  and 
human  beings.  Those  who  are  not  capable  of  understanding  and  evaluat- 
ing both  sides  of  the  architectural  equation  will  not  be  able  to  take  advan- 
tage of  the  potential  opportunities  afforded  by  downsizing,  and  they  may 
be  subject  to  disastrous  consequences. 

The  general  challenge  and  opportunity  of  the  1990s  is  depicted  in  Exhibit 
VII- la.  The  challenge,  simply  stated,  is  to  realize  the  benefits  of  new 
technology  in  the  workplace  before  business  needs/problems  change  and 
before  the  technology  itself  becomes  obsolete  and  causes  adverse  conse- 
quences. Opportunities  exist  for  anyone  (or  everyone)  who  can  make 
effective  use  of  available  technology  that  is  already  in  the  business  envi- 
ronment— not  after  the  next  release  of  the  operating  system  or  after  the 
distributed  data  base  problem  has  been  solved,  but  today — right  now! 

Underlying  this  relatively  understandable  (if  not  simple)  challenge  and 
opportunity  are  the  human  considerations  that  will  determine  not  only  how 
effective  the  application  of  new  technology  will  be,  but  the  definition  of 
effectiveness  itself  This  will  depend  on  the  culture  of  the  organization 
and  the  changes  that  are  either  causing,  or  will  result  from,  downsizing. 
As  we  have  already  pointed  out,  downsizing  is  an  equal  opportunity 
impact  and  challenge  in  that  it  will  affect  the  institutional  culture  at  all 
levels  (Exhibit  VII- lb).  This  has  been  amply  demonstrated  by  the  general 
experience  at  Ford  during  the  1980s,  and  by  the  recent  demise  of  the  CIOs 
in  some  organizations. 
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Giving  direction  to  the  cultural  changes  is  the  responsibility  of  manage- 
ment, and  the  mind-set  of  individual  managers  will  be  more  important 
than  the  organizational  structure  in  which  they  operate  or  the  type  of 
business  they  are  engaged  in.  These  management  mind-sets  are  repre- 
sented by  the  various  schools  of  thought,  previously  defined,  and  shown  in 
Exhibit  VII- Ic.  These  schools  of  thought  will  be  referred  to  as  examples 
of  the  management  challenges  and  opportunities  facing  corporate  execu- 
tives, IS,  users  and  vendors. 
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EXHIBIT  VII-1 


Management,  IS,  User  and  Vendor  Challenges  and  Opportunities 

Systems 

Development 

Process 

(1)             (2)             (3)               (4)             (5)  (6) 
Needs/      Research  Development  Commercial-  Diffusion  Conse- 
Problem                                      ization     &  Adoption  quences 

a.  Hardware 

Systems  Software 
including 

Applications  Enabling 

venaor  ana  lo                               oustness  Neeos  ana 
Responsiveness  Problems 

Applications  Software 

Data  Bases 

   -^v.   ► 

Business  Systems 

Time 

b.  Institutional  Culture 

An  Equal  Opportunity  Impact  and  Challenge 

c.  Schools  of  Thought 

Management  Theory 

Tools  of  Control  Improving  during  Revolution 

"Taylor"  Model 

Mechanization 

Office  "Automation"  and  Paper  Reduction  ^ 

"Living  Systems" 

Philosophy  versus  Reality 

Intelligent  Systems 

Knowledge  Worker  Impact . .  .  Favorable  and  Unfavorable 
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A  

Corporate  Executives 

The  personal  computer  revolution  was  bom  out  of  the  troubled  times  of 
the  1960s  and  among  its  initial  objectives  was  the  stated  intent  to  distrib- 
ute computer  power  to  the  people  and  overthrow  the  establishment.  The 
fact  that  the  technology,  and  many  of  the  early  PC  pioneers,  have  been 
integrated  into  the  establishment  makes  no  difference.  Information  is  now 
viewed  as  power,  and  all  indications  are  that  downsizing  is  as  much  a 
result  of  a  power  struggle  as  it  is  a  technological  phenomenon. 

Corporate  executives  are  being  promised  cost  savings  and  increased 
flexibility  through  the  distribution  of  processing  power  and  data  to  the 
working  level.  On  the  other  hand,  they  are  being  threatened  with  loss  of 
control.  Their  experience  tells  them  that  investment  in  information  tech- 
nology has  neither  improved  white-collar  productivity  nor  improved 
bottom-line  performance.  However,  many  of  them  are  now  too  young  to 
recognize  that  many  of  the  promises  being  made  for  the  new  technology 
are  practically  identical  to  the  promises  of  the  giant  "electronic  brains"  of 
thirty  years  ago. 

The  challenge  for  corporate  executives  is  to  steer  a  course  between  over- 
rating and  undervaluing  technology.  This  requires  the  ability  to  pose 
intelligent  questions  about  certain  fundamental  issues  such  as: 

•  What  is  the  value  associated  with  corporate  data  bases? 

•  What  did  the  "investment"  in  COBOL  programming  buy  the  organiza- 
tion and  what  is  the  value  of  that  investment  now? 

•  How  have  corporate  information  systems  improved  our  competitive 
position  in  the  market,  and  how  will  downsizing  impact  these  systems? 

•  Will  downsizing  improve  the  ability  to  reach  out  and  take  advantage  of 
the  organization's  human  resources,  or  will  it  "devalue"  human  brains? 

•  What  can  computers  do  better  than  people  in  our  organization  and  what 
can  people  do  better  than  computers? 

•  What  are  the  limitations  of  mathematics  in  using  all  of  these  accumu- 
lated data,  and  what  are  the  limitations  of  computers  in  processing  these 
data? 

•  Is  there  really  a  danger  that  we  will  lose  control  of  computers  because 
humans  cannot  possibly  keep  up  with  the  speed  of  communication  and 
the  volume  of  information? 
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•  Who  is  right  among  all  of  the  intelligent  human  beings  who  can't  agree 
among  themselves  about  the  potential  and  impact  of  artificial  intelli- 
gence? 

•  What  are  the  probable  long-range  social  and  general  economic  impacts 
of  all  these  new  technologies? 

•  Will  downsizing  permit  us  to  attract  and  hold  better  quality  people,  or 
will  it  drive  them  away? 

•  Do  we  run  the  risk  of  getting  in  a  deadly  embrace  of  technology  for 
technology's  sake? 

•  Are  we  really  considering  all  of  the  costs  of  downsizing? 

•  Will  downsizing  really  give  the  organization  more  flexibility  or  will 
there  be  no  turning  back  once  we  start  in  that  direction  regardless  of 
consequences? 

•  How  much  trust  do  I  personally  have  in  the  information  provided  by  the 
computer  network  when  I  make  a  query? 

•  Who  will  be  responsible  for  the  quahty  of  information  I  receive  when 
data  bases  are  distributed  and  middle  management  is  "eliminated"? 

•  If  no  computer  and  no  human  can  answer  questions  like  these  for  me, 
what  do  I  do? 

•  If  my  computer  can  answer  questions  like  these  for  me,  why  do  I  need 
any  humans? 

•  How  would  I  feel  about  depending  more  on  computers  than  I  do  on 
human  beings? 

•  If  my  computer  can  ever  answer  questions  hke  these  for  me,  am  I 
needed? 

All  humans,  even  corporate  executives,  must  look  behind  the  screen,  at  the 
screen,  beyond  the  screen  and  then  within  themselves  when  determining 
their  role  in  the  emerging  technological  environment. 

Corporate  executives,  while  they  will  function  primarily  in  the  two  outer 
rings  (Strategy  Formulation  and  Social  System  Development)  of  Zuboff's 
concentric  circles  of  responsibility,  will  also  have  to  understand  and  work 
directly  with  the  inner  rings  (Technology  Development  and  Intellective 
Skill  Development)  and  interface  personally  with  the  core  electronic  data 
base.  Depending  upon  the  accuracy  of  Zuboff's  observations,  that  is  what 
life  will  be  like  "in  the  age  of  the  smart  machine" — and  downsizing  is 
pointing  us  in  that  direction. 
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Some  corporate  executives  will  find  this  extremely  challenging  to  their 
capabilities  and  mind-set;  others  will  consider  it  a  wonderful  opportunity 
for  self-fulfillment  and  corporate  transformation. 

B  

IS  Management 

Downsizing  is  placing  IS  management  in  an  unenviable  position.  Per- 
ceived IS  failures,  expense  and  unresponsiveness  all  helped  weaken  the 
position  of  corporate  planning,  and  the  corporate  controller  used  IS  to 
exercise  the  tight  fiscal  controls  that  are  now  being  blamed  for  the  weak- 
ened competitive  position  of  U.S.  corporations  in  global  markets.  Now  IS 
is  responsible  for  making  downsizing  work.  The  IS  department  will 
receive  little  credit  if  downsizing  is  successful,  but  all  of  the  blame  if  it 
fails. 

We  have  mentioned  the  fact  that  some  CIOs  are  already  beginning  to 
"downsize"  themselves  out  of  a  job.  A  more  likely  scenario  is  as  follows: 

•  The  easy  applications  will  be  downsized  and  turned  over  to  end  users 
who  will  remain  dependent  upon  the  IS  function  as  their  primary  source 
of  data. 

•  Visible  use  of  mainframe  services  (report  generation)  will  decrease 
much  more  rapidly  than  the  costs  of  maintaining  central  data  bases. 
Budgeting  (or  cost  recovery)  for  the  central  IS  department  will  come 
under  increasing  pressure  from  operating  departments  that  now  have 
their  own  IS  expenses  and  want  to  cut  back  their  expenses  for  central 
services. 

•  Some  IS  personnel,  who  feel  bigger  is  better,  will  be  disappointed  that 
growth  possibilities  are  becoming  limited.  It  is  much  easier  to  fmd 
"managers"  who  can  manage  in  a  growth  environment  than  it  is  to  find 
those  who  can  manage  when  times  get  tough.  Finding  and  keeping  good 
IS  personnel  in  this  environment  will  be  a  challenge. 

•  Network  complexity  will  grow  much  more  rapidly  than  the  capability  of 
the  central  IS  function's  ability  to  handle  it,  and  it  will  be  necessary  to 
seek  outside  assistance  in  systems  integration  efforts. 

•  It  will  be  found  that  many  COBOL  programmers  (and  data  base  admin- 
istration personnel)  have  become  glorified  clerks  with  weak  qualifica- 
tions (or  even  aptitude)  for  the  more  complex  programming  and  analysis 
tasks  associated  with  re-engineering  existing  applications  to  take  advan- 
tage of  new  technology  such  as  image  processing  and  knowledge-based 
systems,  or  for  designing  and  maintaining  the  distributed  data  bases  that 
will  be  required. 
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•  Outsourcing  will  become  an  increasingly  attractive  alternative  for  many 
of  the  processing,  maintenance  and  other  systems  support  functions  that 
have  traditionally  resided  in  the  central  IS  department. 

The  challenge  of  distributing  and  sharing  IS  responsibilities  with  end  users 
certainly  may  prove  to  be  the  undoing  of  IS  management — especially 
those  who  have  not  looked  up  from  their  screens  for  the  last  ten  years  as 
management  mind-sets  have  begun  to  change.  However,  for  those  who 
have  been  looking  beyond  the  screen  (or  who  now  answer  the  downsizing 
wake-up  call),  the  opportunities  are  obviously  there. 

If  the  Zuboff  model  is  even  roughly  accurate,  those  who  have  been  close 
to  the  core  in  building  corporate  data  bases  should  be  better  qualified  than 
any  others  in  the  age  of  the  smart  machine.  The  inner  two  rings  of  respon- 
sibility (Intellective  Skill  Development  and  Technical  Development)  can 
be  preempted  by  personnel  with  an  IS  background,  and  the  outer  rings  of 
management  responsibility  will  increasingly  require  the  "intellective 
skills"  that  can  only  be  acquired  by  passage  through  the  inner  rings  and 
knowledge  of  the  core  data  bases. 

Downsizing  is  an  excellent  opportunity  to  apply  information  technology  in 
a  more  effective  manner.  In  many  companies  this  will  mean  a  shift  from 
an  accounting  mentality,  which  views  the  IS  department  as  a  tool  for 
maintaining  control,  to  one  that  emphasizes  a  continual  learning  environ- 
ment throughout  the  organization.  Essentially,  this  is  a  shift  from  the 
Management  Theory  School  of  Thought,  which  was  taught  when  many  of 
the  corporate  MBAs  were  in  business  school,  to  the  "Living  System" 
school  that  is  now  emerging.  This  can  be  viewed  as  the  first  step  in  a 
continual  learning  environment  for  corporate  management. 

It  may  be  difficult  for  some  of  those  who  have  been  "counting  beans"  for 
years  to  move  out  into  the  fields  and  start  growing  them,  but  that  may  be 
precisely  what  is  required.  There  can  be  considerable  satisfaction  in  being 
directly  involved  in  producing  something. 

The  challenge  and  opportunity  for  IS  management  remain  the  same  as 
they  have  over  the  years.  Those  who  identify  with  their  companies'  goals 
and  objectives  rather  than  those  of  technology,  for  the  sake  of  technology, 
are  in  an  excellent  position  to  progress  to  senior  management  in  their 
companies.  Those  who  identify  primarily  with  technology  will  continue 
to  bounce  from  company  to  company  in  a  shrinking  market  for  corporate 
information  systems  "experts." 
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c  

User  Management 

Just  as  IS  management  is  faced  with  a  shrinking  market  for  CIOs,  operat- 
ing management  is  faced  with  the  "elimination"  (or  at  least  reduction)  of 
middle  management.  There  are  going  to  be  fewer  layers  in  the  manage- 
ment hierarchy  as  downsizing  proceeds,  and  user  departments  will  have  to 
become  familiar  with  the  new  technology  as  part  of  the  initiation  rites  to 
the  continual  learning  environment. 

Practically  all  office  and  administrative  work  now  requires  some  familiar- 
ity with  the  personal  productivity  tools  of  personal  computers.  The  client/ 
server  environment,  which  results  from  either  downsizing  or  upsizing,  is 
going  to  require  knowledge  of,  and  participation  in,  distributed  data  base 
and  network  management.  This  presents  the  following  challenges  to  user 
management: 

«  The  technical  challenges  of  becoming  familiar  with  systems  concepts 
and  network  operation  that  go  far  beyond  familiarity  with  spreadsheet 
packages,  and  how  to  reboot  a  PC  if  something  goes  wrong 

«  The  inevitable  requirement  of  becoming  involved  on  a  real-time  basis 
with  the  core  electronic  data  base  (regardless  of  who  has  responsibility 
for  data  quality  as  downsizing  proceeds) 

•  Depending  on,  or  competing  with,  the  IS  "experts"  for  positions  of 
leadership  and  responsibility  in  the  first  two  rings  of  Zuboff's  concentric 
ring  model 

The  "winners"  in  the  PC  revolution  are  now  confronted  with  all  the  prob- 
lems of  what  to  do  with  the  power  they  have  wrested  from  the  central  IS 
department.  Regardless  of  how  bad  things  were  perceived  as  being  be- 
fore, user  management  is  going  to  be  confronted  with  the  responsibility  for 
solving  some  of  those  problems  themselves.  This  can  be  a  sobering 
experience. 

In  many  ways,  downsizing  is  similar  to  what  is  happening  in  the  Soviet 
Union. 

•  The  central  authority  can  be  brought  to  its  knees,  and  all  of  the  tools  of 
power  can  be  seized,  but  underlying  structural  (architectural)  problems 
in  the  economy  (business)  may  become  worse  before  they  can  be  im- 
proved. (There  are  economies  of  scale  associated  with  the  centralized 
data  centers,  which  make  it  probable  that  IS  costs  will  increase — at  least 
temporarily — as  downsizing  proceeds.) 
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•  There  is  also  the  danger  that  parts  of  the  organization  may  go  their 
separate  ways  and  actually  engage  in  power  struggles  among  them- 
selves. (Early  leaders  in  distributed  processing  in  the  1970s  sometimes 
found  that  little  "data-fiefdoms"  developed  as  competing  organizations 
tried  to  build  their  own  power  bases.) 

•  Some  workers  may  not  want  to  be  empowered.  They  are  perfectly 
happy  having  a  job  and  receiving  a  paycheck  and  they  don't  want  to 
compete.  (Zuboff  found  precisely  this  situation  in  one  of  her  case 
studies;  empowered  workers  accused  one  of  their  peers  of  "intellectual 
rate  busting"  when  he  made  suggestions  about  improving  operations. 
Peer  pressure  was  so  strong  that  the  worker  stated  he  would  be  reluctant 
to  make  such  suggestions  again.) 

In  addition  to  all  of  the  other  challenges  to  line  managers,  they  do  not  have 
the  luxury  of  theorizing  about  new  schools  of  thought  about  management. 
They  are  confronted  with  the  day-to-day  problems  of  the  business,  and 
integrating  new  technology  into  business  processes  will  be  difficult  under 
the  best  of  circumstances.  It  will  be  difficult  to  take  a  long-range  view 
incorporating  "intellective  skill  development"  in  either  themselves  or  their 
employees. 

However,  though  the  challenges  to  line  managers  are  formidable,  the  fact 
remains  that  they  have  the  practical  experience  with  business  processes 
that  is  absolutely  essential  for  the  effective  application  of  information 
technology.  It  is  our  opinion  that  the  technical  challenges  of  information 
technology  will  be  easier  for  many  of  them  to  master  than  will  the  realities 
of  the  business  for  information  systems  professionals. 

P  

Vendor  Management 

Vendor  management,  at  all  levels,  is  confronted  with  all  of  the  challenges 
and  opportunities  presented  for  the  general  business  community.  How- 
ever, vendors  have  some  peculiar  problems  all  their  own. 

•  Many  are  confronted  with  severe  technical  and  structural  shifts  in  their 
product  lines.  (The  fact  that  the  AS/400  represents  1 1%  of  IBM's 
resources,  contributes  29%  of  the  revenue,  and  33%  of  income  may 
seem  like  a  simple  management  decision  to  those  outside  of  IBM,  but 
understanding  why  this  is  so,  and  determining  what  to  do  about  it  is 
considerably  more  complex.) 

•  There  is  a  serious  problem  of  product  differentiation  associated  with 
downsizing  hardware  and  software,  which  has  led  to  a  MIPS  race  that 
threatens  both  product  profitability  and  vendor  credibility.  Hardware 
prices  are  dropping  so  fast  there  isn't  even  any  pretense  of  being  able  to 
integrate  the  new  technologies  into  existing  business  systems  before  they 
become  obsolete. 
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«  Many  vendors  are  being  confronted  with  systems  software  complexity 
that  makes  it  extremely  difficult  to  develop  industrial- strength  products 
for  the  downsizing  market — especially  fast  enough  to  take  advantage  of 
rapidly  changing  hardware  technologies. 

•  There  looms  the  threat  of  end  user  resistance  to  increasingly  complex 
and  expensive  hardware  and  software  tools  without  quantifiable  payoff 
in  applications  that  address  real  business  problems.  There  will  be 
increasing  awareness  that  tools  are  not  solutions  as  downsizing  of 
mainframe  applications  proceeds. 

•  Downsizing  is  going  to  expose  customers  direcdy  to  the  consequences 
of  investment  in  information  technology.  The  impact  of  this  exposure 
on  the  markets  for  information  technology  is  highly  speculative.  There 
are  already  those  who  are  beginning  to  question  whether  the  investment 
in  information  technology  in  the  1980s  could  not  have  been  better 
applied  in  product  research  and  investment  in  improving  the  quality  of 
human  resources.  It  is  probable  that  such  questioning  will  increase  as 
downsizing  proceeds. 

•  The  challenge  for  vendors  is  to  facilitate  the  shortening  of  the  innovation 
cycles  at  all  levels  of  the  systems  development  process  so  that  informa- 
tion technology  is  effectively  employed  in  business  systems  as  rapidly  as 
possible.  This  is  a  formidable  task  that  has  defied  simple  solution  over 
the  long  history  of  the  computer  industry,  and  it  is  unlikely  to  be  solved 
by  wrapping  the  information  technology  package  in  another  layer  of 
pretty  wrapping  paper  in  the  form  of  a  GUI.  Downsizing  is  going  to 
make  that  clear  in  a  hurry! 

All  of  these  questions  require  additional  market  analysis  that  is  beyond  the 
scope  of  this  study,  but  INPUT  intends  to  include  a  repon  on  The  Impact 
of  Downsizing  on  IT  Vendors  as  part  of  this  report  series. 

Although  there  is  a  formidable  array  of  problems  facing  information 
technology  vendors,  there  is  unlimited  potential  for  those  who  solve  real- 
world  problems.  Just  as  with  the  "bean  counters,"  the  toolmakers  are 
confronted  with  rolling  up  their  sleeves  and  going  out  to  labor  in  the  fields 
of  integration.  This  integration  is  not  the  integration  of  tools  (box  A  to 
box  B,  and  network  X  to  network  Y — although  these  are  necessary),  it  is 
the  integration  of  information  technology  with  the  "human  architecture"  of 
the  business  enterprise. 

In  summary,  it  is  the  responsibility  of  corporate  executives,  IS  manage- 
ment, users  and  vendors  to  fulfill  the  promises  of  information  technology 
to  contribute  to  both  the  economy  and  the  general  well-being  of  human 
beings.  The  opportunities  for  those  who  can  literally  make  effective  use 
of  information  technology  for  these  purposes  are  unlimited.  Downsizing 
and  the  1990s  are  going  to  be  "roll-up  the  sleeves"  time  for  all  of  us.  The 
die  has  already  been  cast,  we  are  entering  the  long-awaited  "information 
age"  and  there  is  no  turning  back. 
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Conclusions  and  Recommendations 


Compute-intensive  applications  tend  to  seek  their  most  cost-effective 
platform  in  the  processor  hierarchy  because  the  benefits  are  obvious  and 
easily  obtainable.  Commercial  applications,  on  the  other  hand,  have 
tended  to  remain  close  to  their  data  sources  because  the  benefits  are  not  so 
obvious,  and  they  are  not  so  easily  downsized. 

In  addition,  IBM's  System  Network  Architecture  (SNA)  is  essentially  host 
oriented.  This  has  resulted  in  many  commercial  appHcations  remaining  on 
large  host  mainframes  that  do  not  require  the  functionality,  and  burden,  of 
mainframe  systems  software.  The  burden  of  this  top-heavy  architecture  is 
not  only  unnecessary  expense,  but  complexity  that  inhibits  responsiveness 
to  changing  business  needs.  These  are  the  applications  that  are  currently 
the  target  of  downsizing. 

In  some  cases,  more  cost-effective  application  solutions  have  been  avail- 
able for  a  long  time.  INPUT  has  recommended  the  "orderly  distribution" 
of  processing  and  data  from  mainframe  computers  for  over  15  years,  but 
little  progress  has  been  made  during  that  time.  IBM's  System  Application 
Architecture  (SAA)  has  been  around  now  for  four  years,  and  not  a  great 
deal  of  progress  toward  "rightsizing"  has  been  made  under  that  architec- 
ture. It  is  important  for  each  individual  organization  to  understand  why 
this  has  been  so,  because  the  current  trend  toward  downsizing  is  not  an 
orderly  process,  and  mistakes  in  determining  what  can  and  should  be 
downsized  could  be  extremely  costly. 

We  started  this  study  with  the  metaphor  of  a  human  sitting  at  the  computer 
screen.  We  have  looked  behind  the  screen  at  hardware  and  software 
architecture;  we  have  looked  at  the  screen  in  terms  of  the  systems  develop- 
ment process;  we  have  looked  beyond  the  screen  in  terms  of  the  "human 
architecture"  of  management  and  organization;  and  we  have  viewed  all  of 
this  in  terms  of  the  innovation  process. 

One  major  conclusion  we  have  reached  is  that  "downsizing"  is  occurring 
in  both  the  technological  architecture  and  in  the  human  architecture  it 
supports.  If  either  is  to  be  effective  in  accomplishing  its  purposes,  it  is 
necessary  for  the  other  to  succeed.  Therefore,  it  behooves  IS  management 
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to  understand  what  is  going  on  beyond  the  screen,  and  it  behooves  corpo- 
rate executives  to  have  some  understanding  of  what  is  going  on  behind  the 
screen.  It  behooves  everyone  to  understand  what  is  going  on  at  the  screen, 
because  the  relationship  at  the  human/machine  dyad  will  determine  "the 
future  of  work  and  power  in  the  age  of  the  smart  machine." 

However,  this  report  is  directed  to  IS  management,  and  our  conclusions 
and  recommendations  will  focus  on  the  impact  of  downsizing  on  techno- 
logical architecture  and  the  role  of  the  information  systems  function. 

A  

Conclusions 

1.  General 

Some  IS  personnel  have  concentrated  on  looking  behind  the  screen  of 
mainframe  hardware/software  technology  so  intently  they  have  lost  sight 
of  technological  innovations  that  have  occurred  over  the  past  twenty  years. 
While  concentrating  on  what  has  been  going  on  in  the  IBM  world,  they 
completely  missed  minicomputers,  language  developments  other  than 
COBOL,  network  architectures  other  than  SNA,  operating  systems  devel- 
opments other  than  the  evolution  of  OSA^S/MVS,  and  they  even  labeled 
personal  computers  as  "toys"  well  into  the  1980s. 

IS  management  has  been  so  busy  minding  the  data  store  they  don't  know 
what  has  been  going  on  in  the  technological  marketplace.  During  that 
time  the  IS  function  has  become  closely  aligned  with  the  corporate  plan- 
ning and  control  functions.  Those  functions  have  come  under  increasing 
attack  by  operating  management,  and  corporate  executives  are  downsizing 
organizationally  by: 

'   •  Cutting  corporate  planning  staffs  and  loosening  corporate  financial 
controls 

•  EHminating  (or  reducing)  layers  of  middle  management 

Although  the  stated  goals  of  technological  downsizing  are  to  reduce  IS 
cost,  the  management  initiatives  being  taken  require  even  more  investment 
in  IS  technology  at  the  local  level,  with  little  assurance  of  significantly 
reduced  costs  at  the  mainframe  level.  We  say  this  for  the  following 
reasons: 

•  Even  the  most  vociferous  advocates  of  "client/server"  architecture  and 
open  systems  acknowledge  that  most  downsized  applications  will  con- 
tinue to  rely  on  "back  room"  or  "glass  house"  mainframes  for  their  data. 

•  It  is  possible  (and  perhaps  even  probable)  that  activity  on  mainframe 
data  bases  will  actually  increase  rather  than  decrease  as  downsizing 
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proceeds.  This  is  especially  true  during  any  transition  period — and  that 
period  will  be  measured  in  years  in  many  large  installations. 

•  This  problem  becomes  especially  acute  when  "excessive  downsizing" 
occurs.  By  excessive  downsizing  we  mean  an  architecture  that  distrib- 
utes data  directly  to  intelligent  workstations  (and  there  are  those  who 
advocate  this).  Where  this  is  done  the  dependency  on  the  mainframe  is 
extended  until  the  need  for  integration  at  the  local  area  is  recognized — at 
which  time  it  is  discovered  that  what  goes  down  must  come  up,  and 
work  unit  servers  are  installed.  Mainframe  dependency  will  continue 
until  this  cycle  is  completed. 

•  We  do  not  believe  that  "lights-out  operation"  will  be  available  for  very 
many  mainframe  installations.  Those  data  base  administrators  and 
systems  programmers  don't  work  very  well  in  the  dark,  and  while  these 
may  be  viewed  as  custodial  functions,  mainframes  and  central  data  bases 
do  require  a  great  deal  of  tender  loving  care,  as  do  the  more  complex 
SNA  networks  that  will  continue  to  grow  even  as  downsizing  proceeds. 

IS,  which  is  viewed  by  practically  everyone  as  being  part  of  the  problem, 
will  probably  be  held  responsible  for  making  both  technological  and 
organizational  downsizing  work  by  assuring  that  data  quality  is  main- 
tained while  trying  to  integrate  unproven  hardware/software  technologies 
and  user-developed  "applications"  into  reliable  (and  secure)  networks  of 
systems.  This  is  an  unenviable  position  to  be  placed  in  under  the  best  of 
circumstances,  but  it  is  especially  onerous  when  it  requires  taking  all  the 
blame  if  it  doesn't  work,  and  receiving  little  credit  if  it  does. 

It  is  our  opinion  that  organizations  that  fragment  their  information  sys- 
tems, and  virtually  eliminate  the  central  IS  function  (and  the  CIO),  will 
suffer  the  following  consequences: 

•  Increased  information  systems  expense  as  the  result  of  downsizing  (even 
if  these  IS  expenses  are  hidden  in  departmental  budgets) 

•  The  eventual  necessity  to  re-establish  central  responsibility  for  IS  tech- 
nology development,  information  architecture,  enterprise  data  base 
management,  "intellective  skill  development,"  and  (heaven  forbid) 
standards 

•  And,  those  two  consequences  are  the  best-case  scenario,  which  assumes 
that  the  enterprise  will  survive. 

Since  downsizing  is  not  proceeding  on  an  orderly  basis,  it  would  be 
prudent  for  IS  to  adopt  a  course  that  minimizes  technological  risk  in 
pursuing  management's  objectives. 
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2.  Technological  Architecture 

Since  concerns  about  data  base  integrity,  synchronization  and  security  are 
the  primary  factors  inhibiting  downsizing,  we  conclude  that  distributed 
data  base  management  is  of  critical  importance  if  downsizing  is  to  be 
effective  in  achieving  both  technological  and  management  objectives. 

Since  a  high  percentage  of  all  commercial  data  bases  reside  on  proprietary 
IBM  systems,  and  since  the  key  element  in  IBM's  Systems  Application 
Architecture  is  distributed  data  base  management,  we  conclude  that  SAA 
platforms  must  be  considered  when  downsizing.  This  is  necessary  if  only 
for  the  reason  that  interfacing  with  SAA  is  inevitable  for  other  proprietary 
and  open  systems  that  are  data  dependent. 

The  problems  of  distributed  data  base  management  in  a  two-tiered  net- 
work of  large  mainframes  and  intelligent  workstations  become  intractable 
if  significant  portions  of  the  data  base  are  distributed.  In  addition,  there 
are  currendy  no  proven  operating  systems  for  IWSs  that  make  any  pre- 
tense of  supporting  anything  more  than  relatively  simple  file  transfer 
systems.  Therefore,  it  is  our  opinion  that  downsizing  from  mainframes 
should  initially  be  to  minicomputer  distributed  data  servers. 

UNIX  or  UNIX-like  systems  (which  really  become  proprietary  systems  in 
their  specific  implementations)  do  not  have  any  proven  track  record  as 
distributed  data  base  servers.  They  are  high  risk  if  used  in  that  environ- 
ment. Therefore,  proprietary  minicomputer  systems  are  the  safest  choice 
as  DDB  servers. 

It  is  our  opinion  that  IBM's  AS/400  is  currently  the  best  DDB  server.  It 
dominates  the  midrange  commercial  market  and  has  a  superior  architec- 
ture for  distributed  data  base  management.  It  has  a  proven  track  record  of: 

•  Easy  installability 

•  Low  operating  and  support  expense  (operations,  systems  support,  train- 
ing, and  data  base  administration) 

•  Superior  connectivity  and  network  management  facilities 

•  Ready  availability  of  a  wide  variety  of  applications 

•  High  reliability,  availability  and  serviceability 

•  Excellent  architectural  scalability 

•  About  the  only  thing  lacking  is  enthusiastic  vendor  support  for 
downsizing  from  System/370  architecture  mainframes  to  AS/400s  under 
the  SAA  umbrella. 
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The  fact  that  IWSs  have  been  ruled  out  as  distributed  data  base  servers, 
does  not  mean  they  have  no  role  to  play  in  the  downsized  environment.  A 
number  of  appHcations  functions  will  "pass  through"  the  distributed  data 
base  server  directly  to  IWSs  if  downsized  applications  are  properly  re- 
engineered.  Even  more  important  is  the  fact  that  new  applications  devel- 
opment in  support  of  organizational  downsizing  will  be  concentrated  at  the 
IWS  level. 

Exhibit  Vni-1  presents  downsized  applications  and  functions  in  a 
"proper"  hierarchical  network  for  the  1990s.  It  is  our  opinion  that  this 
type  of  network  will  evolve  even  if  it  starts  with  bottom-up  system  devel- 
opment (or  if  excessive  downsizing  occurs),  but  our  specific  concem  is  an 
architecture  for  applications  that  minimizes  the  risks  inherent  in 
downsizing. 

•  The  mainframe  becomes  a  superserver  that  is  fundamentally  burst  (or 
batch)  oriented.  The  systems  software  for  mainframes  started  with  a 
batch  orientation,  and  the  amount  of  sorting  that  still  takes  place  on  large 
mainframes  indicates  that  the  operation  hasn't  changed  all  that  much 
despite  hanging  on  terminals  for  transaction  processing.  The  primary 
roles  of  the  superserver  will  be  to: 

-  Serve  as  a  network  transaction  and  data  reservoir — a  massive  store- 
and-forward  system  for  transactions  and  data 

-  Provide  an  archival  data  warehouse,  including  "bonded  storage"  for 
enterprise  data  (such  as  "intellective  skills  data  bases")  and  a  central 
library  of  electronic  publications  on  optical  disk 

-  Provide  backup  for  distributed  applications  and  data  in  the  event  of 
network  failure  or  overload 

-  House  the  enterprise  network  repository  necessary  for  data  base  and 
network  management.  (Yes,  the  repository  will  live  on — or  will  be 
reincarnated.) 

•  The  DDB  servers  (by  definition)  will  provide  distributed  data  base  and 
network  management  among  other  DDB  servers  and  superservers,  and 
to  the  clients  in  their  work  units.  They  will  also  serve  as  the  primary 
links  to  the  outside  world  (see  also  Exhibit  IV- 1)  where  they  will  screen, 
identify  and  route  calls  and  "filter"  data  from  outside  sources.  In  addi- 
tion, they  will  be: 

-  The  primary  data  processing  engines  for  downsized  applications,  and 
will  serve  as  back  up  for  applications  functions  passed  through  to 
clients  during  downsizing 

-  The  coordination  points  for  office  systems  and  services  within  the 
work  unit  and  across  the  network  as  required 
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The  repository  for  work  unit  objects,  and  the  library  for  work  unit 
reference  documents  and  archives 


The  connectivity  and  routing  engines  for  intra-  and  internetwork 
communications  for  work  unit  clients 


EXHIBIT  VIII-1 


Downsized  Applications  and  Functions 

(T)  Transaction  Reservoirs 
(2^  Archival  Data  Warehouses 
(T)  Backup  for  Distributed  Applications 
(4^  Enterprise  Repository 


Superservers 
Magnetic  & 
Optical 


Downsized  Applications 


Magnetic 
and  Optical 


L  —  ^ 

DDB 
Servers 

DDB 
Servers 

Any  Topology; 


RISC 
IWSs 


Gateway  to  and  from  Outside  World 

(T)  Distributed  Data  Base  Mgmt. 
Network  Management 
'  ^  (?)  Integration  of  Business  Systems 
Object  Management 
(J)  Connectivity 

Downsized  Functions 


(T)  Compute  Intensive 

^2)  Knowledge-Based 

(3)  High-Resolution  I/O 
Driver 


(T)  Data  Capture/Editing 
(2^  Report  Preparation 
(3^  Personal  Data  Bases 
(7)  Personal  Productivity 
(5^  Continuous  Learning 


Q)  Automated  Processes 
(T)  Secure  Processes 
(T)  Data  Entry  and  Editing 
(7)  Information  Retrieval 


•  A  variety  of  local  and  remote  clients  will  be  supported  by  DDB  servers. 
One  of  the  primary  purposes  of  DDB  servers  is  to  break  down  the  walls 
of  the  work  unit  and  permit  flexibility  in  bringing  together  appropriate 
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"intellective  skills"  work  units  regardless  of  geographic  location.  Cli- 
ents are  then  located  as  close  to  the  source  of  the  transaction,  skill, 
knowledge  or  data  source/destination  as  possible.  Representative  clients 
and  their  functions  are  shown  in  the  diagram,  but  they  are  not  intended 
to  be  definitive  or  restrictive.  Those  shown  are: 

-  RISC  workstations  being  used  for  compute  intensive  applications  such 
as  CAD/CAM,  know  ledge- based  systems,  and  as  the  drivers  for  high- 
resolution  I/O  devices;  these  clients  may  be  either  loosely  or  tightly 
integrated  with  the  DDB  servers  (and  may  even  be  under  the  same 
cover  in  some  configurations). 

-  Personal  computers  being  tightly  integrated  with  DDEs  as  the  primary 
clients  for  downsized  applications  functions  such  as  data  capture  and 
editing,  report  preparation  and  information  display,  personal  data 
bases,  and  personal  productivity  tools;  in  addition,  these  clients  will 
be  the  focus  and  vehicle  for  "continuous  learning." 

-  Diskless  workstations  to  mechanize  clerical  processes,  data  entry, 
routine  information  retrieval,  and  to  provide  secure  processes  under 
direct  control  of  the  server;  the  workstation  engine  will  be  determined 
by  the  processing  requirements  of  the  automated  process,  but  cost  will 
be  kept  to  a  minimum. 

Walking  around  this  architecture  enables  us  to  identify  all  four  schools  of 
thought,  and  we  conclude  they  will  all  be  served  by  the  downsizing  archi- 
tecture. 

•  The  Management  Theory  school  that  represents  tight  central  cost  control 
and  planning 

•  The  Mechanization  school  that  emphasizes  work  simplification  and 
mechanization  (and  along  with  the  Management  Theory  school  consti- 
tutes the  Taylor  Model  referred  to  by  Matsushita) 

•  The  "Living  System"  school  that  was  explored  by  Zuboff 

•  The  Intelligent  System  school,  which  has  come  to  be  associated  with 
Herbert  Simon,  has  been  eternally  slow  in  delivering  on  promised 
results.  However,  it  seems  to  be  relied  upon  in  some  of  the  downsizing 
initiatives  currently  being  undertaken  by  management.  The  purpose  of 
intelligent  systems  is  to  capture  human  knowledge  and  skills  and  move 
the  interface  of  the  human/machine  dyad. 

Though  all  of  the  management  schools  of  thought  are  served  by  the  archi- 
tecture that  has  been  depicted,  this  does  not  mean  that  the  management 
mind-set  of  either  corporate  or  IS  executives  has  changed  to  embrace  all  of 
these  schools.  Management  mind-set  will  determine  where  emphasis  will 
be  placed  in  the  architecture  and  how  effective  it  will  be  in  implementa- 
tion. 
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The  downsizing  architecture  also  helps  in  understanding  Zuboff' s  manage- 
ment model  as  it  applies  to  information  systems  and  the  IS  function. 

3.  Organizational  Architecture 

In  order  to  decentralize  planning  and  control  to  operating  units  of  the 
organization  and  at  the  same  time  eliminate  layers  of  middle  management, 
it  seems  obvious  that  some  combination  of  the  following  must  occur: 

•  The  remaining  employees — whether  they  are  executives,  managers, 
supervisors,  project  leaders  or  just  plain  workers — are  going  to  have  to 
work  longer  and  harder  (which  already  appears  to  be  the  case). 

•  And/or,  the  remaining  employees  are  going  to  have  to  work  a  lot 
"smarter." 

•  And/or,  the  remaining  employees  are  going  to  have  to  be  empowered 
with  improved  information  systems  that  relieve  them  of  some  of  the 
additional  burden. 

•  And/or,  the  artificial  system  must  become  "intelligent"  enough  to  substi- 
tute for  some  of  the  experience  and  knowledge  that  was  previously 
applied  to  the  information  flow  by  middle  management. 

It  is  probable  that  all  four  of  the  above  will  be  required,  to  some  degree,  if 
the  implementation  of  the  downsizing  management  initiatives  that  are 
currently  under  way  are  going  to  be  effective.  It  is  therefore  concluded 
that  the  remaining  employees  will  be  drawn  closer  to  the  core  electronic 
data  base  of  the  Zuboff  management  model  (in  terms  of  understanding  and 
use),  and  the  core  itself  must  expand  significantly  as  more  data  are  added 
(especially  in  terms  of  experiential  decision  rules).  This  will  result  in 
compression  of  the  Zuboff  concentric  rings  of  management  responsibility 
(Exhibit  VIII-2). 

The  exhibit  also  clearly  shows  the  importance  of  the  technological  model 
in  maintaining  (and  improving)  the  quality  of  the  core  electronic  data 
base(s).  There  is  a  big  difference  between  capturing  facts  (such  as  sales, 
inventory,  work  in  process,  etc.),  and  information  pertaining  to  human 
interactions  and  decision  making  (skills,  knowledge,  performance  and 
personal  characteristics).  These  more  complex  data  vary  in  validity  and 
reliability,  but  they  form  the  most  important  elements  of  Zuboff's  "intel- 
lective skill"  core  (whether  they  are  in  human  heads  or  in  data  base 
servers).  These  raw  data  should  not  be  stored  or  distributed  to  every 
desktop  in  the  enterprise — or  exposed  in  any  way  to  unauthorized  access 
or  contamination. 
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EXHIBIT  Vlll-2 


Organizational  Architecture 


(T)  Intellective  Skill  Development 

(2)  Technology  Development 

(3)  Strategy  Formulation 

(4)  Social  System  Development 


Building  and  maintaining  the  core  electronic  data  base  is  a  formidable 
challenge  on  the  leading  edge  of  both  computer  and  mathematical  science 
(to  say  nothing  of  artificial  intelligence,  which  cuts  across  many  disci- 
plines). Accessing  these  data  is  one  thing,  understanding  their  quality  and 
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usefulness  is  going  to  be  quite  another,  and  building  the  artificial  systems 
that  take  full  advantage  of  these  data  is  frequently  beyond  the  current  state 
of  the  art  in  information  systems.  This  leads  to  the  following  conclusions: 

•  It  is  apparent  that  "intellective  skill  development"  in  terms  of  both 
building  and  using  the  core  date  base  will  be  considerably  more  difficult 
than  explaining  the  use  of  the  latest  spreadsheet  package. 

•  The  task  of  "technology  development"  is  currently  formidable  and  can 
only  get  more  complex  and  challenging  during  the  1990s. 

•  It  is  unreasonable  to  expect  employees  in  user  departments  to  be  of 
much  assistance  in  either  of  these  areas,  much  less  to  provide  the  neces- 
sary leadership  in  the  downsized  environment. 

We  also  conclude  that  "strategy  formulation"  and  "social  system  develop- 
ment" will  be  increasingly  dependent  on  the  underlying  information 
architecture  and  technology.  The  quality  of  data  will  determine  the  quality 
of  strategic  decisions,  and  the  quality  of  information  systems  (at  the 
screen)  will  determine  to  large  degree  the  social  system  that  evolves. 

It  appears  that  competent  IS  employees  (at  all  levels)  have  little  to  fear 
from  downsizing.  They  will  be  needed  and  have  an  even  more  important 
role  to  play  in  the  age  of  the  smart  machine. 

It  seems  apparent  that  lowering  IS  costs  is  not  necessarily  a  reasonable 
objective  if  organizational  downsizing  is  to  be  successful.  However,  the 
objective  of  a  leaner,  more  competitive  organization  may  be  all  the  justifi- 
cation that  is  needed  for  downsizing. 

If  reduced  costs  are  necessary  to  justify  management  downsizing,  these 
savings  must  come  from  improving  human  information  systems  of  all 
kinds.  Since  artificial  intelligence  and  knowledge-based  systems  remain 
high  risk  in  terms  of  both  difficulty  of  implementation  and  probability  of 
cost  savings,  it  will  be  necessary  to  concentrate  on  improving  business 
processes.  (In  fact,  these  will  have  to  change  if  layers  of  middle  manage- 
ment are  to  be  eliminated. 

It  will  be  necessary  to  re-engineer  many  downsized  applications  if  existing 
processes  are  going  to  be  improved.  One  of  the  most  attractive  opportuni- 
ties for  improving  processes  is  the  reduction,  or  elimination,  of  paper.  The 
core  data  base  is  electronic,  not  paper. 

Properly  implemented,  downsizing  affords  the  opportunity  to  improve  the 
applications  development  process.  There  is  broad-based  management 
support  for  downsizing,  and  end  users  can  be  involved  in  the  application 
development  process.  These  are  two  of  the  elements  INPUT  has  tradition- 
ally cited  as  being  necessary  to  improve  productivity  in  software  develop- 
ment. 
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We  conclude  that  downsizing  affords  substantial  opportunity  for  improv- 
ing both  IS  practice  and  recognition. 

B  

Recommendations 

The  first  recommendation  is  that  IS  management  should  take  downsizing 
seriously  and  view  it  as  an  opportunity  to  improve  the  quality  of  informa- 
tion systems  and  their  contribution  to  management  objectives.  Fears  of 
downsizing  the  CIO  out  of  a  job  should  be  put  aside.  That  isn't  going  to 
happen  if  downsizing  is  to  accomplish  management's  objectives. 

Downsizing  should  begin  with  a  commitment  to  quality,  and  that  will 
usually  require  re-engineering  existing  applications. 

End  users  should  be  involved  in  the  downsizing  effort  from  the  begin- 
ning— especially  those  that  require  improved  business  processes.  End 
user  involvement  is  a  benefit  of  downsizing  if  it  is  approached  on  a  team 
basis  rather  than  an  "us  and  them"  attitude.  The  most  effective  personnel 
should  be  assigned  to  projects  based  on  their  skills  and  abilities  rather  than 
their  organizational  affiliation. 

IS  management  should  take  the  leadership  in  "intellective  skill  develop- 
ment" at  all  levels  in  the  organization.  It  should  be  pointed  out  to  manage- 
ment that  there  is  an  inherent  power  shift  associated  with  increased 
reliance  on  the  core  electronic  data  base,  even  if  this  is  not  what  they 
intended. 

The  question  of  cost  savings  should  be  analyzed  on  an  objective  basis. 
There  should  be  no  unpleasant  surprises  or  hidden  costs  of  moving  some 
responsibilities  to  end-user  departments.  A  thorough  cost  analysis  frame- 
work should  be  established  that  includes  all  of  the  potential  costs  (see 
Exhibit  V-3). 

IS  management  must  do  an  objective  analysis  of  mainframe  applications, 
and  accept  responsibility  for  those  that  obviously  could  benefit  from 
downsizing.  This  requires  becoming  familiar  with  existing  technologies 
that  could  be  used  for  downsizing,  and  with  the  business  processes  associ- 
ated with  those  applications.  Work  with  users  in  defining  the  best  candi- 
dates. 

INPUT  recommends  that  you  do  your  own  report  card  on  the  possible 
alternatives  as  distributed  data  base  servers.  As  part  of  this  process,  we 
recommend  that  you  take  a  careful  look  at  both  the  AS/400  and  UNIX  as 
well  as  PC-based  LAN  servers.  Do  not  reject  new  or  unfamiliar  technolo- 
gies that  may  be  of  benefit  in  the  downsizing  effort.  Do  this  evaluation 
even  if  it  requires  considerable  effort.  For  example: 
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•  It  may  not  be  possible  to  get  very  good  information  from  an  IBM  sales 
representative  whose  orientation  (and  compensation)  is  based  on  main- 
frames. You  may  have  to  seek  other  sources  of  knowledge — including 
current  users. 

•  It  is  also  difficult  to  find  objective  opinions  concerning  the  quality  of 
UNIX  (especially  in  all  its  various  forms).  It  may  be  necessary  to  do 
some  desk  and  field  research. 

•  At  the  workstation  level  there  is  no  substitute  for  trying  various  alterna- 
tives, if  you  have  not  already  done  so. 

We  recommend  a  careful  analysis  of  the  need  for  distributed  data  bases  as 
downsizing  proceeds.  If  they  are  really  not  necessary,  you  may  be  able  to 
simplify  your  architecture  considerably.  However,  as  part  of  this  analysis, 
play  a  file  transfer  scenario  through  to  completion  and  try  to  visualize  the 
potential  integration  problems  that  may  develop  as  downsizing  proceeds. 

Use  Exhibits  Vni-1  and  VIII-2  as  models  and  analyze  any  technical  or 
management  limitations  in  implementing  such  a  model  in  your  organiza- 
tion. Give  special  attention  to  any  discontinuities  between  management 
expectations  and  technological  reality — especially  in  terms  of  the  ability 
to  transfer  human  knowledge  and  experience  to  the  core  electronic  data 
base. 

Develop  a  long-range  information  architecture  with  the  cooperation  and 
understanding  of  both  corporate  and  user  management.  Put  this  architec- 
ture in  the  electronic  data  base  so  that  everyone  can  have  ready  access  to  it 
even  when  absorbed  in  the  details  behind  the  screen. 

Prepare  a  downsizing  plan  that  is  consonant  with  this  architecture  and 
includes  anticipated  shifts  in  IS  and  management  responsibilities  that  are 
necessary  (or  probable)  in  your  organization,  and  the  potential  conse- 
quences of  these  shifts. 

Work  with  management  and  end  users  in  making  certain  that  these  conse- 
quences are  understood  and  accepted. 

Prepare  a  long-range  (10-year)  technological  forecast  and  scenario  that 
will  expand  on  the  consequences  of  information  technology  innovation  in 
the  1990s,  and  relate  this  scenario  to  your  company.  In  other  words,  look 
beyond  the  screen  and  beyond  downsizing  to  the  technological  and  man- 
agement architectures  of  the  future.  Although  there  may  be  many  factors 
beyond  the  control  of  any  individual  or  organization,  it  is  important  to 
anticipate  the  business  environment. 


©  1992  by  INPUT.  Reprcjduction  Prohibited. 


UIDSA 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


Assume  your  responsibilities  for  "intellective"  skill  and  technical  develop- 
ment. Information  technology  innovation  is  the  most  important  fact  in  the 
1990s  business  environment,  and  it  is  INPUT'S  belief  that  IS  management 
must  accept  the  responsibility  for  leadership  in  the  management  of  these 
innovations. 


©  1992  by  INPUT.  Reproduction  Prohibited. 


vm-13 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


©  1 992  by  INPUT.  Reproduction  Prohibrted.  U I DSA 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


Bibliography 


[I]  Large  Scale  Systems  Directions,  (INPUT,  June  1986),  Report  on 
IBM  large-scale  systems  roadshow. 

[2]     What  Can  Be  Automated?',  The  MIT  Press  Series  in  Computer 
Science  1980. 

[3]     AS/400  Announcement  Package,  8/88  attributed  to  William  O. 
Grabe,  IBM  Vice  President  (then  with  Applications  Business  Sys- 
tems). 

[4]     "UNIX  Operating  Systems  Security",  FT.  Grampp  &  R.H.  Morris; 
Bell  Laboratories  Technical] ournal.  Volume  63,  No.  8  Part  2, 
October  1984. 

[5]     "Systems  Architecture  in  Transition  -  An  Overview",  H.  Lorin;  IBM 
Systems  Journal,  Volume  25,  Nos.  3/4,  1986 

[6]     "Image  processing:  Finally,  a  solution  to  'the  paper  chase'";  THINK 
magazine,  IBM. 

[7]      "Efficiency  expert"  (Chart)  page  29,  Computerworld,  2/3/92. 

[8]     General  System  Theory,  Ludwig  von  Bertalanffy;  George  Braziller, 
Inc.,  1968. 

[9]      Perspectives  on  General  System  Theory,  Ludwig  von  Bertalanffy; 
George  Braziller,  Inc.  1975. 

[10]   "Productivity  Assessment  of  Office  Information  Systems  Technol- 
ogy"; James  H.  Bair;  Emerging  Office  Systems,  Ablex  Publishing, 
1982. 

[II]  Microsoft  Bookshelf,  Microsoft  Corporation,  1 99 1 . 

[12]    "Diffusion  of  Innovations"  (Third  Edition);  Everett  M.  Rogers;  The 
Free  Press,  1983 

[13]   "Different  Perspectives  on  Information  Systems:  Problems  and 
Solutions";  Kalle  Lyytinen;  ACM  Computing  Surveys  Vol.  19, 
No.l;  March  1987 


©  1992  by  INPUT.  Reprodualon  Prohibited. 


A-1 


SYSTEMS  ARCHITECTURES  FOR  DOWNSIZING 


INPUT 


[14]   "Managerial  Implications  of  the  Evolution  of  the  Organization 
Information  System";  van  Gigch,  Le  Moigne,  Roberts,  &  Tyler, 
Presented  at  Advanced  Executive  Seminar  (SAM),  Milan,  Italy;  Jun 
89 

[15]   In  the  Age  of  the  Smart  Machine:  The  Future  of  Work  and  Power, 
Shoshana  Zuboff,  Basic  Books,  Inc. 

[16]   Managing  on  the  Edge:  How  the  Smartest  Companies  Use  Conflict 
to  Stay  Ahead;  Richard  Tanner  Pascale;  Simon  &  Schuster,  1990. 

[17]   "When  the  CIO  becomes  expendable",  by  Clinton  Wilder, 
Computerworld,  2/17/92.  page  16. 

[18]   The  Principles  of  Scientific  Management,  Frederick  Taylor,  New 
York  and  London:  Harper,  1929. 

[19]    Originally  from  Wiener's  Cybernetics  quoted  in  John  von  Neumann 
and  Norbert  Wiener,  Steve  J.  Heims;  MIT  Press,  1980. 

[20]  "Call  for  business  to  eliminate  middle  managers",  Mary  Madison; 
p.C-12,  Peninsula  TimesTribune,  2/21/92.  (Attributed  to  William 
Davidow  in  address  to  Commonwealth  Club) 

[21]   "Application  System/400  -  Facts  Folder",  Eighth  Edition;  IBM  Corp, 
February  1992. 


A-2 


S  1992  by  INPUT.  Reproduaion  Prohibrted. 


UIDSA 


